Continuous delivery pipeline tools build IT efficiency
The range of CD tools available is as varied as the organizations that need them. Choose between three primary tool set constructions to suit your organization's structure.
When practiced properly, continuous integration and continuous delivery add speed and flexible iteration to the development process, helping organizations bring software to market faster, with more innovation and fewer flaws. It requires process-centric automation created by tightly integrated continuous delivery pipeline tools that precisely shepherd each code version from inception through deployment.
Continuous delivery pipeline tools. The underlying process of each CI/CD step can be complex, and those processes must happen quickly and repeatedly -- sometimes, several times each day. Tools are, therefore, critical to continuous delivery success or failure.
An overarching automation server takes continuous delivery from coding to release, moving the product through the pipeline. The particular areas of focus in the pipeline include CI's coding, build and code test and CD's orchestration, deployment and monitoring. Examples of tools for each step are listed in the table.
Coding/build tools. Continuous delivery usually starts with the continuous integration tools needed to code, commit and build each new release. Developers use coding platforms and integrated development environments (IDEs) to write software. Code is stored in version control tools.
Table 1. Examples of continuous integration and continuous delivery pipeline tools. This list is only a brief overview of the individual tools available.
Version control tames confusion in a continuous software development setup. A software product typically is composed of many components, and each component gets updated at a different frequency and independent of the others. This means a lot of moving parts go into every build, so version control tools help developers track each component and ensure that every build or release candidate has the latest correct package of components.
Build tools draw from the version control system to translate and compile the code components into an executable instance.
The choice of coding tools often depends on the language(s) in use and the product's target platforms, such as Windows computers or Android smartphones.
Review/testing tools. Every build must be tested against relevant criteria to ensure it is consistent and meets the organization's needs and expectations for the product. For example, it's common to test software against security standards and under common modes of attack. Testers also perform a thorough examination of dependencies.
Acceptance testing evaluates the user's ability to work with new or improved product features and can help to identify features that are underutilized or poorly implemented. For example, an acceptance test identifies if GUI dialog boxes have inconsistent styles and button placement or if navigation is clear.
In addition, defect (bug) testing captures and documents errors and oversights in the code, such as malfunctions in the UI, trouble accessing important files and other unexpected or unwanted behaviors. Performance testing ensures that the build behaves within acceptable parameters under expected user load, processing the expected number of transactions per second. Manual testing can vet the build for specific nuances that automated testing tools cannot readily model.
There are many examples of continuous delivery pipeline tools for build testing. They enable developers to review and collaborate on code changes and defect control. A version control browser feature enables developers to identify differences between code versions, which will lead to problems in production.
Deployment/orchestration tools. Once a build passes testing and becomes a release candidate, the focus shifts to software release. The continuous delivery paradigm integrates development and operations teams that must collaborate and share pipeline tools.
Automated system configuration prepares one or more systems within the data center or cloud resources to receive releases.
Consider the deployment environment when selecting operations tools. Some products are designed to provision to specific public cloud platforms, while others natively work with diverse deployment targets, from the data center to cloud, even for the same release.
Automated system configuration prepares one or more systems within the data center or cloud resources to receive releases.
Some deployments require middleware to support the application's runtimes. For example, highly transactional Java applications and services require Java application server runtime platforms or Java servlet containers.
Monitoring tools. Continuous delivery does not end when the build deploys. Monitoring verifies the performance and stability of each release, gathers important metrics and reports operational details to the development team to guide subsequent releases.
Incident management and issue tracking systems help organize bug reports, feature requests and more.
IT organizations that assemble individual continuous delivery pipeline tools have the most flexibility. They can build a tool set to meet unique needs and even tailor varied tool sets for different development teams. But the onus is on the organization to select tools that integrate properly and craft the scripts and policies that keep the pipeline functioning. It's a tall order, and some organizations may opt for more integrated tool sets.
Plentiful pipelines
There is no single ubiquitous tool list for perfect continuous integration and continuous delivery. The intended process and project goals of the pipeline should drive the tool choices -- not the other way around. Consequently, a single CD tool set might not be the best choice for a business, and instead different development groups within a business could utilize differing tool sets to accommodate needs or accomplish specific tasks. For example, a team developing apps for Android devices selects build, test and deployment tools that are dramatically different than those for a team developing a Java-based web application or for another team developing conventional middleware in C++. Yet, all of those disparate teams can use the same automation, issue tracking, collaboration and version control tools.
Integrated pipelines
Individual tools are not always desirable for an organization because it can become cumbersome to oversee, integrate and update individual tools in local deployments, even when they come from a single vendor.
Some vendors deliver integrated continuous delivery pipeline tools as a cloud service. Users can integrate open source and third-party tools with the vendor's services as well. IBM Cloud Continuous Delivery is an example, and the major public cloud providers are also serving this market, as evidenced by Google Cloud Platform's Cloud Build, Cloud Source Repositories and Cloud Tasks.
While integrated and cloud-based tool sets can simplify the choice of tools and streamline the learning curve, users can also be limited by the features and capabilities of the integrated tool set. In addition, users give up a certain amount of control over tools provided as a service and must work with any changes the vendor makes -- even unwanted changes.
Table 2. One example of an integrated CI/CD pipeline comes from CA, which sports a range of offerings capable of taking a code iteration from inception through deployment.
CD tool set interoperability
These long continuous delivery tool lists underscore the importance of interoperability.
Understand how each tool in a given pipeline interoperates with the others. The output of one tool must be suitable input for the next step's tool with little or no conversion or post-processing of the data. As one simple example, the text file produced by a code editor must be easily read and acted upon by the build tool that compiles it. Similarly, a testing tool must easily interact with the resulting executable or other artifacts of the build.
Many file types and formats to code, build, test and deploy software are reasonably standardized, which enables many tools to interoperate. Verify the interoperability of the pipeline tools at initial selection and each time a tool changes.
Interoperability remains a vital attribute of any integrated CD tool set, and the suites described from CA, IBM and Google typically underscore compatibility with at least some third-party tools. For example, CA's Automic Release Automation can interoperate with Jenkins as an orchestration platform -- enabling Jenkins to orchestrate some build tasks, while CA tools handle others.
