As I mentioned in the previous post, Octopus Deploy is a release management and deployment automation tool, which shines exactly when You need to automate the deployment process to multiple environments, like test/stage/prod, for example:
The automation is really the key here and this is why:
- So-called 'right-click' deployments from Visual Studio look sexy only during the demos
- In the real life, your enterprise application infrastructure will be much more complicated. Imagine a couple of API endpoints/web services. Multiple background jobs or Windows services, web portal itself. Let's not forget that in production everything mentioned above usually lives in clusters, meaning you have to deploy the same artifacts to multiple machines. Right-click deployment is simply not an option out there
- In the ancient times we as an industry used to have a manual deployment process powered by checklists. Some companies still do that. Despite check-lists are better than nothing, they are still error-prone, usually doable by one guy (the release-manager, which might be a bottleneck). In addition to that, the issue is that one successful deployment does not guarantee, that it is repeatable, since human-factor plays a huge role in manual deployments
- Rebuilding your code so you can deploy it is generally considered as a bad practice. People usually do that to apply config transformations. Octopus Deploy model allows You to have the same version of your application/artifacts/packages and move it between different environments, applying config transformation at deployment time, rather than compile time. This ensures the same packages are being tested in all your environments before getting to production
- Do you really need different packages per configuration? It leads to inconsistency. A Good practice is considered not to have different packages and change configuration at deploy time, not compile time. Taking this into account you can create brand new environments (like for launching UI tests, etc.) without recompiling existing packages. We can make an analogy with .NET Standard here: any packages compiled with .NET Standard in mind could be used in any new platform which will appear later on and implements this standard (without recompiling the package)
- A release is a snapshot of deployment artifacts (packages), process and config transformation variables, which means that you can change the process or config variables, but still deliver previous releases with their initial configuration
- Simple math always works: just go ahead and calculate how many hours the company saves if so-called release nights (where a dozen of engineers participate) will be replaced with automated deployments
- Taking everything mentioned above into account, you can have more aggressive deployment cycles. Ship small bits and be more confident. Since the smaller pieces you deploy, the less risk you have