Simple deployment process in middle-size project, #3: Octopus

The previous article describes a configuration of the TeamCity server used in our ATM project. This time next and the last of the main steps of deployment process – configuration of the Octopus server. With TeamCity building new code and pushing built packages to the storage and Octopus picking them and deploying to virtual machines we have a full loop that allows testers/developers to start the deployment with one click only.

From Octopus homepage: „Octopus takes over where your Continuous Integration server ends, enabling you to easily automate even the most complicated application deployments, whether on-premises or in the cloud.” This description seems to be understandable and shows exactly what is it for. The tool is free even for commercial purposes even though free version limits are quite painful (I think it supports up to 5 projects, users, and 10 agents). With very small project it’s more than enough though. Even in slightly bigger we were able to bypass these restrictions. Unfortunately, from a certain point we had to move to the enterprise license and now no problems occur.

As before, I’m showing configuration steps as the gallery of screenshots. If you have some remarks or questions please contact me freely. I will try to answer any question related to this article.

1 z 58

One more remark: In my previous post about TeamCity, on slides 33-35 I described how to push packages to the Octopus and start deployment process remotely, each time nightly build happens. Of course, the setup presented here may be later tuned according to emerging needs – this is how it works in my project. First I created this basic skeleton to have something automated, and since that time I’ve been adding features to comply with new requests from the supervisors. Maybe I will share few tips in the next posts 🙂