When deploying software manually, the tendancy is to deploy once a month or perhaps once every two or three months. Deployment doesn’t stop for production only, there are test, staging and production as well.
Manual deployment can lead to human errors and consume a huge chunk of man-hours to fix. Adopting automation significantly addresses the issues with eliminating human errors, deployments become faster and not only that, their habits change as well, with the ability to deploy more frequently with many times a week, even daily. The benefits of automated deployment are proven in the chart below.
Why does that matter?
When a bug is fixed or a feature is developed, it is best delivered to the client rather than sitting for the next release in months. The sooner you deliver the new feature is sooner the client gets the values for it, and sooner you get feedback and that improves. A feature or a bug fix waiting for deployment is like inventory waiting for sale that doesn't make money for you.
So how does automation increase the frequency of deployment? Here are the factors:
- Less downtime due to faster deployment
- Less amount of people required to execute the deployment process
- Reliable deployment process, due to lack of human errors
- More frequent deployments due to all above facts
- Frequent deployments helps out resolving bugs faster
How does an Automated Deployment Tool can assit you?Your team might already be using a source control tool, like TFS, Git, Mercurial or Subversion. Say, you already have a build server or CI (continuous integration) server in place, like JetBrains TeamCity, Team Build or Cruise Control. A tool like Octopus can fit into your existing software delivery pipeline by building on top of it. With a tool like Octpopus Deploy, the automated deployment pipeline look like this:
- Developers commit their code changes to source control
- Your build/CI server compiles your code, runs unit tests runs, BDD tests, and bundles the applications into packages
- Octopus deploys those packages to your test, staging and production environments
Note that deployments could be triggered in a few different ways. For example:
- Your build/CI server might trigger a deployment to a test environment as soon as the build finishes
- You might allow testers and developers to "self service" deploy to pre-production environments
- Release managers/operations teams can trigger production deployments
Packaging applications
Before an application can deployed, it needs to be turned into a package. Think of a package as being like a ZIP file containing all of the binaries, scripts, CSS files, images and configuration files needed for your application to run. Octopus Deploy uses the NuGet package file format.
Secure deployments
Tentacle, a lightwieght agent service, will deploy your applications to multiple servers in multiple environments., which you install on each of the machines that you plan to deploy software to. Octopus uses SSL to push packages and deployment instructions to the Tentacles, and the connection uses a two-way trust relationship: similar to SSH in the Linux/UNIX environments.
Managing configuration differences
Different environments, have different configurations when it comes to deployment. This might require different connection strings in test and in production. You might need to set a password for an SMTP server, or an API key for an external API. To support these scenarios, Octopus has the concept of variables. Octopus can even automatically update the configuration file using these variables during deployment, or pass them to powershell scripts for you to perform custom actions on deployment.
Packaging your applications for deployment
Before you can deploy an application using Octopus, you will need to bundle all of the executables, DLL's, configuration files, installation scripts, and anything else the application needs to run into a package.
Creating projects
Once your applications have been packaged, you can create a project to deploy them. A project is a set of deployment steps that you want Octopus to perform, and any related configuration variables. You'll create a project for each group of applications that you plan to deploy together.
Define your deployment process
Your deployment process is like a recipe, specifying all of the steps Octopus Deploy will perform when you deploy your project to an environment.
