"Our highest priority is to satisfy the customer through early and continuous delivery of valuable software." The ability to accelerate time to market is one of key factors that enables teams to take on this Agile principle
from the Agile Manifesto.
For many organizations, continuous integration and delivery are key focus areas that help them deliver high-quality software at frequent intervals. The major requirement of any Agile transformation is to have an ability to deliver continuously at regular intervals so that the customers can see working software and give timely feedback. Teams need a mechanism of "quick delivery of working software and the availability of testable builds" that enable them to test their increments and deliver quality software at frequent intervals.
With organizations that have many teams and massive code bases, just having a continuous integration and delivery process would not alone suffice for achieving quick time to market. Imagine a scenario in which millions of check-ins are happening every day. One of the main bottlenecks I see for such organizations is the inability to make testable builds available as quickly as possible. To the teams, this is the biggest challenge holding them back from timely delivery of working software to customers.
This build process is often rigorous, and it takes a significant amount of time for the build to get completed. To realize the fruits of continuous delivery and continuous deployment, there needs to be in place a robust infrastructure for supporting daily builds, centralized build process control, automatic build notifications, and so on for a successful Agile build environment. So an extensive automation framework needs to be built on top of the continuous integration process to speed up the availability of testable builds to enable the teams to test their solutions quickly. There are many options in the market for setting up such an infrastructure, and I see the concept of a private cloud as one of the options.
The main idea behind any of these solutions is to provide a feature that makes a build machine available that would enable the identification of any issue well in advance of reaching the customer. Fixing something identified by the team in the sprints may take an hour, but the same fix could take ten times more time if logged by the customer, due to the overhead process involved in fixing the issue and delivering the fix.
Let us try to briefly summarize the need for an automation layer over the continuous integration/delivery system:
Quick access to setups (build machines) of any configuration, without any delays or queues.
Build generation process should be quick.
Central monitoring of all builds.
Immediate notifications to all in case of any build failure and availability of a testable setup with a click of a button to test the failure and fix it.
All these trigger a need for automation on top of the continuous integration process to help quick, quality delivery and timely feedback.
Given the organization's need for security and data privacy, private cloud could be one of the options to build an automation layer over the existing continuous integration layer. There could be many other options as well.
The concept of private cloud lets you create virtual machines that replicate the end-user machines very quickly. The exact process of doing this varies from organization to organization and the process of virtualizing is out of the scope of this article, as there are many ways to do it. Using the cloud concept, it is easier and quicker to spawn any number of testable build machines by using high-end servers. Hence by combining automation, cloud, and virtualization (cloud) under one umbrella, the impediment of availability of physical machines for testing the work items could be resolved mostly by replicating the physical machines with virtual-build machines, which is indeed a boon in today's fast-paced environment.
Some of the benefits of having an automation layer over the continuous integration and delivery layer are:
The quality of the delivered software would improve as teams would be able to test their working software on testable builds.
Quick delivery as the generation of testable machines is quick, and once the solution is tested it is ready for delivery.
Predictability increases, as there would be a significant reduction in technical debt due to continuous testing on the end-user testable machines.
Decreased downtime, etc.
To conclude, automation linked with continuous integration and delivery would yield faster and quicker results with greater impact. Teams need to start realizing such a need and drive the change!