Anyone who has worked in the software industry will tell you that writing code is just one part of the development process. The code, so written, needs to go through a host of checks and measures before being given a thumb up for deployment. Deployment to a production server is another process in itself – taking anywhere from a week to months’ time.
Because the deployment is a slow process – it takes ages (metaphorically speaking) before an update to a software suite is available to the users. Now, while there’s nothing wrong with this process, except being excruciatingly slow – what if there was another way, a different approach to software development and deployment which could drastically cut down your product’s ‘time to market’.
This is where the concept of deployment pipeline comes into picture. Conceptually, a deployment pipeline is like a path laden with tests and checks, which a new piece of committed code has to pass through to be eligible for deployment. At the end of the path is the holy land of production – a one button click process to ship the code to deployment. Deployment pipelines are a part of the ideology of DevOps, a merge of Development and Operations skillset to reduce the chaos that goes with a new release.
There are three major parts constituting a deployment pipeline:
1. Build Server (Dev)
A build server, essentially, automates the merging of a new release with the current code base. Tools facilitating the automation of building a Dev Server are also called Continuous Integration (CI) tools. A few of the more popular CI tools are:
- Jenkins – Published under the MIT license, Jenkins is a free-to-use and open source CI tool built in Java. One of the biggest advantages that Jenkins brings with it, is the extensibility via huge list of plugins.
- Bamboo – Bamboo is Atlassian’s CI tool, and comes in two versions – self hosted and hosted. It’s easily configurable with a host of other tools provided by Atlassian (Jira and BitBucket) – making for a coherent suite.
- Go CD – Go is another free of cost CI tool, built by ThoughtWorks. It is available in Windows, Mac as well as some Linux versions.
Confused about which CI tool to use for your deployment pipeline? Let our expert CI consultants help you out.
2. Testing Environment
Once the code is built by the Build Server, it is moved to the testing environment, where it is subjected to multiple test suites. Automated testing is the real value proposition of a deployment pipeline. Test suites are built to test the Dev build using various parameters. There could be one test suite that performs Unit Testing, another suite performing Integration Tests and another testing the build from a functional perspective.
It is the job of the test suites to prove that the code is not ready for production. They are designed to catch known bugs and issues. Of course, the test coverage dictates the amount of manual testing required. But even automating certain parts of testing can bring in a higher level of efficiency.
Most of the process under the deployment pipeline is automated. This gives you the power to deploy a build to any of the environments. Be it testing, staging or even production.
In some cases, when a build passes all the automated test suites and has undergone a manual check, the build can be deployed to production directly with a few steps.
Setting up a deployment pipeline with continuous integration and continuous deployment (CI/CD) is a big change for any organization. The advantages of adopting a DevOps mindset are a plenty, but we understand that the change happens slowly over time. The ideal way to approach this is to start small. Automating parts of the deployment cycle, one at a time, will hedge the risks.
If you’re interested in exploring the benefits and the process of setting up deployment pipelines for your organization, our expert consultants can help. Drop us a message here.