Continuous Integration is an enormous step forward in productivity and quality for most projects that adopt it. It ensures that the teams working together to create large and complex systems can do so with higher level of confidence and control then is achievable without it. CI ensures that the code that we create (as a team) works by providing us with rapid feedback on any problems that we may introduce with the changes we commit. It is primarily focused on asserting that the code compiles successfully and passes a body of unit and acceptance tests. However, CI is not enough.
CI mainly focuses on development teams. The output of the CI system normally forms the input to the manual testing process and rest of the release process. Much of the waste in releasing software comes from the progress of software through testing and operations. For example, it is common to see
- Build and Operations teams waiting for documentation or fixes
- Testers waiting for “good” builds of the software
- Development teams receiving bug reports weeks after the team has moved on to the new functionality
- Discovering, towards the end of the development process, that the application’s architecture will not support the system’s non functional requirements
This leads to software that is undeployable because it has taken so long to get it into a production-like environment, and buggy because the feedback cycle between the development team and the testing and operations team is so long.
In Continuous Delivery, a software team plans to deliver software in short cycles. They perform development, testing and release in such a short time that incremental changes can be easily delivered to the production. In Continuous Delivery, as a DevOps we create a repeatable deployment process that can help achieve the objective of continuous Delivery.
Getting a Deployment Pipeline is the basis of Continuous Delivery. Some of the basics about deployment pipeline are
- The purpose of the deployment pipeline is to give everyone involved in delivering software visibly into the progress of builds from check-ins to release.
- It should be possible to see which changes have broken the application and which resulted in release candidates suitable for manual testing or release.
- Your implementation should make it possible to perform push-button deployments into manual testing environments.
- Choosing to release a particular version of your application should also be a push-button task that can be performed with full knowledge that the release candidate being deployed has passed the entire pipeline successfully and hence has had a battery of automated and manual tests performed on it in a production-like environment.
- Once you have deployment pipeline implemented, inefficiencies in your release process will become obvious. All kinds of useful information can be derived from a working deployment pipeline, such as how long it takes a release candidates to get through the various manual testing stages. Once you have this information, you can work to optimize the value-stream.
- There is no one size fits all solution to the complex problem of implementing a deployment pipeline. The crucial point is to create a system of record that manages each changes from check-in to release, providing the information you need to discover problems as early as possible in the process.
- A Deployment pipeline, in turn, depends on having some foundations in place
o A good configuration management
o Automated scripts for building and deploying your application
o Automated tests to prove that your application will deliver value to its users
o Discipline to ensure that only changes that have passed through the automated build, test and deployment system get released.
This adoption path consists of one practice that focuses on establishing business goals and adjusting them based on customer feedback: continuous business planning.
Businesses today need to be agile and able to react quickly to customer feedback. Achieving this goal centers on an organization’s ability to do things right. Unfortunately, traditional approaches to product delivery are too slow for today’s speed of doing business, partially because these approaches depend on custom development and manual processes and because teams are operating in silos. Information required to plan and re-plan quickly, while maximizing the ability to deliver value, is fragmented and inconsistent. Often the right feedback isn’t received early enough to achieve the right level of quality to truly deliver value.
Teams also struggle to incorporate feedback that should inform the prioritization of investments and then to collaborate as an organization to drive execution in a continuous delivery model. For some teams, planning is viewed as governance overhead that’s intrusive and slows them down instead of an activity that enables them to deliver value with speed. Faster delivery provides greater business agility, but you must also manage speed with the trust and confidence that what you’ve delivered is the right thing. You can’t deliver software at speed if you don’t trust the accuracy of your business goals, your measurements, and your platforms.
DevOps helps to reconcile these competing perspectives, helping teams collaboratively establish business goals and continuously change them based on customer feedback thereby improving both agility and business outcomes. At the same time, businesses need to manage costs. By identifying and eliminating waste in the development process, the team becomes more efficient but also addresses cost. This approach helps teams strike an optimal balance between all these considerations, across all phases of the DevOps life cycle in moving to a continuous delivery model.
This adoption path involves two practices: collaborative development and continuous testing. As such, it forms the core of development and quality assurance (QA) capabilities.
Software delivery efforts in an enterprise involve large numbers of cross-functional teams, including lines-of-business owners, business analysts, enterprise and software architects, developers, QA practitioners, operations personnel, security specialists, suppliers, and partners. Practitioners from these teams work on multiple platforms and may be spread across multiple locations. Collaborative development enables these practitioners to work together by providing a common set of practices and a common platform they can use to create and deliver software.
One core capability included within collaborative development is continuous integration a practice in which software developers continuously or frequently integrate their work with that of other members of the development team.
Continuous testing means testing earlier and continuously across the life cycle. This results in reduced costs, shortened testing cycles, and achieved continuous feedback on quality. This process is also known as shift-left testing , which stresses integrating development and testing activities to ensure quality is built-in as early in the life cycle as possible and not something left to later. This is facilitated by adopting capabilities like automated testing and service virtualization. Service virtualization is the new capability for simulation of production-like environments and makes continuous testing feasible.
An organization can introduce continuous deployments without major architectural modifications. The continuous deployments reduce the time required to place a component into production, however, requires architectural support
- Deploying without the necessity of explicit coordination with other teams reduces the time required to place a component into production.
- Allowing for different versions of the same service to be simultaneously in production leads to different team members deploying without coordination with other members of their team.
- Rolling back a deployment in the event of errors allows for various forms of live testing.
Microservice architecture is an architectural style that satisfies these requirements. This style is used in practice by organizations that have adopted or inspired by many DevOps practices. Although project requirements may cause deviations to this style, it remains a good general basis for projects that are adopting DevOps practices.
A Microservice architecture consists of a collection of services where each service provides a small amount of functionality and the total functionality of the system is derived from composing multiple versions of a service in production simultaneously and to roll back to a prior version relatively easily.
Having an architecture composed of small services is a response to having small teams. The DevOps goal of minimizing coordination among various teams can be achieved by using a microservice architectural style where the coordindation mechanism, the resource management decisions and the mapping of architectural elements are all specified by the architecture and hence require minimal inter-team coordination.
A collection of practices for development can be added to the microservice architectural style to achieve dependency and modifiability, such as identifying and isolating areas of likely change.
Adopting a microservice architectural style introduces additional challenges in a monitoring, debugging performance management and testing. Migrating from an existing architecture to a microservice architectural style requires careful planning and commitment.
The Deploy adoption path is where most of the root capabilities of DevOps originated. Continuous release and deployment take the concept of continuous integration to the next step. The practice that enables release and deploy also enables the creation of a delivery pipeline. This pipeline facilitates continuous deployment of software to QA and then to production in an efficient, automated manner. The goal of continuous release and deployment is to release new features to customers and users as soon as possible.
The Operate adoption path includes two practices that allow businesses to monitor how released applications are performing in production and to receive feedback from customers. This data allows the businesses to react in an agile manner and change their business plans as necessary.
Continuous monitoring provides data and metrics to operations, QA, development, lines-of-business personnel, and other stakeholders about applications at different stages of the delivery cycle. These metrics aren’t limited to production. Such metrics allow stakeholders to react by enhancing or changing the features being delivered and/or the business plans required to deliver them.
Continuous Customer Feedback and Optimization
The two most important types of information that a software delivery team can get are data about how customers use the application and feedback that those customers provide upon using the application. New technologies allow businesses to capture customer behavior and customer pain points right as they use the application. This feedback allows different stakeholders to take appropriate actions to improve the applications and enhance customer experience. Lines of business may adjust their business plans, development may adjust the capabilities it delivers, and operations may enhance the environment in which the application is deployed. This continuous feedback loop is an essential component of DevOps, allowing businesses to be more agile and responsive to customer needs.