What Tools Do You Need for Continuous Delivery?

Software organizations strive to deliver good quality software to their customers based on the need and market requirements. However, the business needs are not static and they change continuously based on the changing market requirements. Organizations also know that software is difficult to ship, and all the development activities can be completed for the software (requirement, design, code, build, test), but when it comes to deployment, there are frequent issues and consequently, organizations take time to deploy the software in the production environment. 

Hence, the organization has to find a reliable method to develop, release and modify software easily and frequently without issues. Continuous Delivery is a set of practices that is facilitated by a toolset that exists precisely to resolve this problem that continues to dog organizations which aim at releasing stable software more frequently. Continuous Delivery is able to meet this need as it focuses on automation, testing at every stage in the process, regular code releases, and pull based architecture (as compared to push based architecture), which allows only successful releases to go to the next stage. This reduces overall errors and helps to promote stable, quick, and frequent sofware delivery. Continuous Delivery builds on agile practices and also requires a cultural mind set shift in the organization apart from the technical shift. This also implies that testing and IT operations people need to get involved earlier in the software design process and thus, DevOps practices need to be well developed in order for continuous delivery to succeed in the organization. 

However, the most important aspect to note in the execution of continuous delivery is that the right set of tools need to be used to facilitate the CD practices. This ensures appropriate communication between Dev, Test, QA, and IT infrastructure team members. All the tools which enable CD also have another thing in common: everything including IT Infrastructure is treated as code. This ensures that all the steps in the process work flow can be automated, and Dev and Ops can converse using the same language and tools. This implies that an application (software) focused approach to infrastructure ensures that the infrastructure responds automatically when the application needs to run efficiently. 

Applications need storage, computing, and network requirements. Now we can configure everything to support an application using tools that are based on the principles of "Infrastructure as Code" and "Infrastructure as a Service (IAAS)". When we adopt tools to manage the complete software delivery pipeline, all the members (Dev, Test, QA, Ops) can provision the environment for the application as per the requirement at each stage of the software development cycle. This ensures reduction of errors in the software delivery pipeline and all the members are on the same page regarding the status of software delivery. 

In order for all these aspects to be addressed appropriately by Continuous Delivery, we need to focus on the appropriate toolset that will help us to succeed in this process. There are many tools in the market for facilitating continuous delivery. However, by focusing on the most commonly used tools and customizing the tool requirements as per the specific requirements of the project and the organization, it is possible to implement continuous delivery practices successfully. Adopting one tool and the practices associated with it will help the software team to become comfortable with the tool. Subsequently, other tools can be adopted over a period of time. In this way, all the continuous delivery practices can be implemented successfully. 

The continuous delivery tools adopted by the industry across the different categories are numerous and vary widely. Some of the common tools used across the different categories are given below:

1. Continuous Integration - This is a very important practice that is the cornerstone of continuous delivery. This enables pull-based architecture, and the commonly used tools are:

   • Jenkins - An open source continuous integration tool with automated continuous
     build and monitoring of externally-run jobs (e.g. cron jobs).

   • Hudson - An open source continuous integration tool with automated continuous build and monitoring of externally-run jobs (e.g. cron jobs).

   • Team City - Proprietary continuous integration system that integrates with Git and
     Mercurial.

   • Cruise Control - It is both a continuous integration tool and an extensible framework for creating a custom continuous build process.

   • Bamboo - A proprietary tool that runs builds and tests.

   • Go - An open source continuous integration tool.

   • Travis - A proprietary continuous integration system.

2. Version Control - It is the core of continuous integration. Development teams use version control to keep a record of every version of every feature, add-on or any other change to the code base. The commonly used tools are - 

   • Subversion - An open source version control system (VCS) that is used for version control of code.

   • Team Foundation Server - Microsoft’s VCS. Includes continuous integration, issue
     tracking, and other features.

   • Git - An open source version control system that’s distributed, so you can check in code and merge it while you are working offline.

   • Mercurial - It is an open source distributed VCS where you can check in code and merge it while working offline.

   • Perforce - A proprietary version control system that supports Git.

3. Code Review - It is a systematic examination of computer source code. These tools help the developer to step through code and see where the differences in code are present. It also helps to note which changes are acceptable and which are not before changes are merged with the main code base. The commonly used tools are:

   • Crucible - A proprietary collaborative code review tool. 

   • Gerrit - A web-based code review tool that helps online code review using the Git version control system.

   • GitHub - An online repository for collaboration, code review and and code management. 

   • Stash - A proprietary tool for reviewing code in Git with enhanced features. 

4. Configuration Management - A configuration management tool helps you to keep environments consistent throughout the software development process, from the developer’s laptop until production across all the stages of the delivery pipeline.  The commonly used tools are:

   • Chef - It is a configuration management (CM) tool written in Ruby, and it is used for automating configuration management tasks. 

   • Puppet - A configuration management platform that is available both as an open source project and as a proprietary tool for enterprise companies. It is used for automating server management and other tasks. 

   • Ansible - Ansible seamlessly unites workflow orchestration with configuration management, provisioning, and application deployment in one easy-to-use and deploy platform.

   • Vagrant - It is a CM tool for building complete development environments. With an easy-to-use workflow and focus on automation, Vagrant lowers development environment setup time and increase development/production parity. 

5. Monitoring - Infrastructure monitoring tools enable us to collect and analyze data in testing environments, as well as other parts of the infrastructure. Monitoring gives the
   team data that show whether the performance is improving or deteriorating and thereby corrective measures could be taken to improve the performance. When undertaking a staggered deployment of various tool sets, this set of tools could be one of the first tools to be deployed in the organization to measure the performance of the application. The commonly used tools are: 

• Logstash - An open source tool for managing logs and other event data from your systems.

• Graphite - An open source tool for storing data and rendering it graphically.

• Nagios - A monitoring and alerting tool for applications, servers, switches, and services.

• Splunk - A tool for monitoring and visualizing data from your website, applications, servers, networks, and other devices.

6. Orchestration - Orchestration tools focus on the configured environment to manage the changes, updates, or complete applications in any specific order. Automating orchestration greatly reduces the possibility of human error. The configuration management tools generally also perform the orchestration activities needed for managing the configured environment. The commonly used tools are: 

   • Chef - It is a tool written in Ruby and it is used for automating orchestration steps (extension to Chef. Chef-metal allows you to use the core Chef principles to manage other aspects of your infrastructure. For example, when using Amazon Web Services (AWS), we can manage core AWS components such as Elastic Load Balancers (ELBs), Simple Queue Service (SQS) queues, compute resources, and other components using chef-metal). 

   • Puppet - It facilitates automation of orchestration tasks.  Puppet Enterprise makes it possible to drive change and easily orchestrate ordered deployments across your infrastructure and applications. You can run phased, canary deployments exactly when you want and fully control the roll out of changes, whether to an isolated set of your infrastructure, a specific application, or your entire data center. 

   • Ansible - Ansible seamlessly unites workflow orchestration with provisioning and application deployment in one easy-to-use and deploy platform. The clear syntax and task based nature of the tool helps in automating the orchestration tasks effectively. 

7. Dashboards - These tools help to communicate the status of an environment to the entire team at all times, e.g. if the build is broken (red) or the build is working (green), and the set of components/packages released into each environment. The dashboard should display the status of your test environment and production environment. It should show the status of each node, physical server, and virtual machine.  Most continuous integration tools also help in communicating the status of the environment, and have dashboards that give complete information about the status of the environment and release. Dashboards are basically a collection of widgets that give you an overview of the reports and metrics you want to focus. We can monitor many metrics and hence we can quickly check the account status or see correlations between different reports. Dashboards should be easy to create, customize, and share. The commonly used tools are :

• Jenkins - An open source continuous integration tool with automated continuous
  build and monitoring of externally-run jobs (e.g. cron jobs). The dashboard displays the status and progress of each job. Various plugins are available to create good dashboards using the tool. 

• Bamboo - A proprietary tool that runs builds and tests. The dashboard is the Bamboo home page which shows Bamboo's agents and build queue, showing which plans Bamboo is currently building and which plans are waiting to be built and other information. 

• Go - An open source continuous integration tool and which has dashboards that communicate the status of the environment. 

Continuous Delivery is an ongoing collaboration between the people who are part of the software creation process (Dev) and the people who are part of the release process (Ops). 

You’re doing Continuous Delivery practices when you can perform push-button deployments of any version of the software to any environment on demand. You are using using a pull-based architecture that permits only successful releases to move to the next stage, using automation, undertaking frequent releases and testing at every stage of the process and you also work together as a single team and every member - developer, QA and IT Infrastructure/Sysadmin are responsible for delivering quality code. In order for us to ensure that we meet all these requirements, tools are used in continuous delivery to implement the processes successfully. 

Another important point to keep in mind is that sometimes the commonly used tools may not be suitable, and the organization may develop its own tools to meet the requirements, e.g. Monitoring tools developed by the organization in-house for proprietary applications which may not allow for interaction with other commercial tools due to security and other factors. 

Conclusion

Hence, the organization needs to have an over arching and judicious strategy to come up with a list of tools for the various continuous delivery practices and have a pilot run to decide on the tools that will eventually be used by it and then deploy the tools in a staggered manner over a period of time so that the organization becomes comfortable with the entire panoply of tools and is able to sustain the continuous delivery practices over a period of time. 

This will eventually help the organization to become more successful in making incremental, automated, quality, and fast deliveries and be responsive to the changes in the market place and meet the customer requirements effectively in the long run and also reap the return on investment (ROI) expended on the tools used for continuous delivery.