Winning in business often means being the first one out there with a product but traditional software development processes don't support this.
Agile Methods Aren't Enough
Agile software development processes were developed to reduce those barriers. Rather than mapping out the complete project requirement, writing all the code and doing a big-bang test and deployment, the project is broken into a series of smaller sprints. Ideally, the team is able to quickly deliver functionality via frequent releases.
That approach still leaves developers working independently on individual features and the project has a delivery date when all those efforts are supposed to be checked in and tested before being deployed to production. Developers do their own unit testing, but that doesn't guarantee that all the changes made were compatible.
Indeed, finishing a build in this way often results in certain problems:
• When developers work from local code bases, they don't know how their changes will affect other developers' work.
• Build scripts aren't updated to incorporate new third-party components.
• Conflicting versions of libraries cause delays in bringing a build to the test environment.
Always Having a New Working Version
Continuous integration helps by automating these process. Tools like Jenkins can be used to perform test builds on a regular schedule. Sometimes there's a nightly build and smoke test, which is performed automatically and alerts the developers when the build or test fails. Sometimes the process is performed even more frequently. It's well known that the earlier a bug is found, the cheaper and easier it is to fix it, so teams usually require that all development stops until the build is fixed.
The built package just sits around, though, until all the features of the sprint or release are ready for testing. Sometimes this means delaying the release date until a feature that's fallen behind is done. Sometimes enough time goes by that management makes a decision to pull that feature out of the release and move ahead without it. Finally, the build completes testing successfully and the package moves to production.
This means there's a long period where there's code that's ready for a test but has not yet been tested. Continuous delivery changes that. By using tools like Jenkins, companies can define a pipeline that automates builds, tests and packaging for every feature. With Jenkins, there's always a package with new functionality that's tested, solid and ready for deployment. Companies can even use continuous deployment to automate the deployment process. In some businesses, new builds can be installed as often as several times a day.
Not every business would want to do that; sometimes downtime needs to be carefully managed. But even for those that still manage deployments manually, the continuous delivery process offers many advantages:
• Deliver features, not releases. End users don't care about a release; they care about getting the functionality they need. Focusing on features lets developers and the business share common priorities. Because any subset of functionality can be released, developers learn to test thoroughly and focus on quality, rather than planning to come back to it later.
• Flexibility in responding to competition. You've always got a build that's ready to go. You can quickly respond to a competitor's features with your own release. Or tempt customers by providing a small set of the functionality they're clamoring for, instead of making them wait for a major release. You'll also get more frequent feedback, and be able to respond to it faster.
• Production support is easier. Because of heavy use of automation, DevOps teams can work more closely with developers. It's easier to roll out applications; they're smaller, with fewer changes, and less risk. If there are production problems after a package is deployed, the small number of features included makes it easier to identify the source of the problem. It's also easier to make the changes needed to fix it.
Tools to Facilitate Continuous Delivery
Getting continuous integration, continuous delivery or continuous deployment to work right requires using the right tools. Many companies skimp on spending to support their development teams, but fortunately, there are open source products that developers can use.
Work with a tool to build a pipeline that automates the entire process. It can pull the latest code from the VCS, then run the build script to create the executable. The next step in the pipeline is to run automated tests. Different kinds of tests can run in parallel; there's no reason to wait for static analysis to complete before running tests. While testing needs to be "good enough," in most environments you don't need to run a complete regression test that takes weeks to complete. Unless the application is providing core functionality in a highly regulated industry, most production issues are not critical. While you still want and need to do thorough testing, the ability to deploy fixes quickly means the risk and impact of production bugs is manageable.
Some tools commonly used to build pipelines and automate the process are:
• Jenkins. An open source continuous integration platform, a plugin simplifies creating the pipeline. Ant, maven, and custom scripts control the processes.
• CircleCI. CircleCI offers easy integration with GitHub to support continuous integration of mobile, web, browser, and containerized applications. It will automatically infer build commands by looking at the source repository.
• TravisCI. Like CirclCI, TravisCI integrates with GitHub and provides defaults for multiple languages. The complete build process, including steps to be performed before and after deployment, can be automated.
• CodeShip. Codeship offers continuous integration as a service. It supports 10 parallel pipelines to increase testing speed.
Precautions to Take
The technology needed for continuous delivery isn't complicated, but making the mental shift to the process can be challenging. Agile methods speed development, but don't always result in rapid deployments. Continuous deployment and continuous delivery sound risky, but by focusing on the actual end product of the software development process, they help companies achieve the end results they want.