Hi,
I’m hoping you can help with a best practice on how to implement a CI/CD with TeamCity and Octopus
My setup is as follows
TFS2015 – Source Control
TeamCity 9.1.4 (Waiting for 10 to be released before upgrading) – CI server
Octopus Deploy 2.6.5 (Will be upgrading to latest in the next couple of weeks) – Deployment server
Within our system we have multiple Applications (micro services) which are decoupled however are ultimately used together to be one application. I want the option to be able to deploy each individually and keep the build as small as possible.
Project 1
Project 2
Project 3
Project 4
The following scenario happens:
- If changes are made to project 1 this will deploy into a devci environment for this track and only deploy the changes for this project. Next changes are made to Project 3 and again on checkin this deploy and only this is deployed. All of this works fine as I have a trigger on all solutions at this level to trigger a build on checkin which in turn does a build then deploys to the devci environment!
- I want to run a promote of the binaries on all environment to our qa environment. Is there any way of using octopus deploy or promote to say deploy all 4 project, this then checks the latest version which have been built already and tries to push these through Octopus. Now before actually deploying however it check to see if these binaries have already been deployed and if they have it will skip the deployment… in the scenario above it will skip Projects 2 and 4 as they have not had any changes made to them?
If you believe this has been fixed in later releases this is also an option!
Kind Regards
Dave
Hi Dave,
Thanks for getting in touch! I’ve been writing some examples to give you the best answer possible, but it’s taken me longer than I’d hoped. Rather than keep you waiting too much, here’s some initial thoughts to get started:
- Octopus doesn’t currently have first-class support for Projects interacting with each other, or multi-project deployments. Projects are generally considered as completely independent entities.
- Many customers who want to achieve this kid of behaviour with Octopus today will write some tooling (scripts or mini-applications) that leverage the Octopus API. There are lots of examples of using the API here, and I was hoping to provide something specific for your situation where you could query the Dashboard API to find the current Releases deployed to an Environment, and promote those Releases to the next Environment.
- There is a TeamCity plugin that can be used to make TeamCity into an orchestrator for more complex, inter-project, orchestrations: http://mjrichardson.com/blog/teamcity-octopus-deploy-plugin/
- In Octopus 3.4 we have implemented Project Triggers for auto-deployment as a baseline to start building other interactions between different parts of Octopus. Take a look at our guide for working with elastic and transient environments. I can imagine at some point we may allow you to trigger a deployment when another Project finishes a successful deployment, for example.
Hope that helps! It would be great if you could get back to me with your thoughts and we can progress from there.
Have a great weekend!
Mike
Hi Mike,
I’ve managed to put something together using octo.exe to examine the release numbers and diff them and then only deploy if the release is greater.
Kind Regards
Dave
Hi Dave,
Thats great news! Don’t hesitate to reach out if we can help in any other way.
Happy Deployments!
Mike