Continuous Delivery

The authors start by illustrating their goal building a deployment pipeline, which is an automated implementation of the application’s build, deploy, test, and release process. They discuss the common antipatterns prevalent in software releases today, and the benefits of their approach. They also briefly discuss that to achieve their goal, the software needs to be frequently and automatically released. Finally they discuss some of the principles of software delivery like reliable releases, automation, version control, continuous improvement etc.

The authors describe Configuration Management as the process by which all relevant artifacts for a project and the relationship between them are stored, retrieved, uniquely identified and modified. They highlight how version control fosters collaboration among teams distributed in space and time. The authors recommend checking in everything in trunk on a regular and frequent basis and oppose the practice of using branches. The authors also emphasize the importance of testing and proper management of configurations. They stress the importance of managing the environment by creating a fully automated process. Thus they try to highlight the importance of configuration management which is the foundation for continuous integration, release management and deployment pipeline.

The goal of continuous integration is that the software is in a working state all the time. The teams that use continuous integration effectively are able to deliver software much faster, with fewer bugs, than teams that do not. Bugs are caught much earlier in the delivery process when they are cheaper to fix, providing significant cost and time savings. The authors describe how to implement continuous integration by discussing the prerequisites and how to get started by setting up the CI server. They also discuss tools like Maven and Ivy to help manage third-party dependencies of the development workspace. They describe continuous integration as a software that can execute a workflow at regular intervals and provide a detailed view of success and failures of the builds and tests. The authors then discuss essential practices to make continuous integration effective. Thus authors point out that an established CI system is a foundation on which more infrastructure can be built. It provides visibility by aggregating the build information to provide high quality feedback and can be extended to do push-button deployments.

This chapter focuses on the planning and impementation of effective automation testing systems and their benefits. The authors encourage writing testing scripts from the beginning of the project and running them within the deployment pipeline which is triggered whenever any change is made to the application. They describe the different types of tests in detail like acceptance tests, unit tests, component tests and deployment tests. Manual testing techniques like showcases, usability testing and exploratory testing are important to build quality. They talk about modern automated functional testing tools like Cucumber, JBehave, Concordion and Twist and their benefits. They describe the process by which testing strategy can be implemented by bringing together all the stakeholders to note down the highest priority scenarios every iteration and then building automation for them. Thus authors highlight that automation testing should be included from the beginning to develop a feedback loop which generates higher quality, higher productivity and also the measure of the doneness of the project.

The authors describe deployment pipeline as the process of automating the build, deploy, test, and release process to deliver the feature from check-in to release. They describe the different stages of deployment pipeline and the best practices which should be followed in each of those stages. They also describe the steps to implement a deployment pipeline. Feedback is important in software delivery and can be measured by various metrics. The authors suggest having a global metric like cycle time to measure feedback and its measurement should be simple and made visible to discover bottlenecks. Thus the deployment pipeline should help in discovering which check-ins have caused issues and should allow everyone involved in software delivery to get visibility into the progress of builds.

The authors describe the techniques of creating an automated build and deployment process. They categorize the build tools into task oriented and product oriented tools describing their properties and the principles common to all the build and deployment tools. They also describe the advantages and disadvantages of some commonly used build tools like Make, Ant, Maven, Rake, Buildr. They discuss some of the best practices commonly used in the deployment setup for any application. The standard project layout used by Maven is described which gives a good idea for structuring any application. The strategies and best practices to solve common build and deployment problems are discussed. The authors emphasize that the deployment scripts should be version-controlled, maintained, tested, and refactored and should be the only way to deploy the software.

In this chapter authors describe the commit stage which is the first stage of the deployment pipeline and discuss about creating effective commit tests. They describe the principal goal of the commit stage which is either to create deployable artifacts or fail fast and notify the developers of a concise summary of the reasons for the failures showing a list of failed tests, the compile errors or other error conditions. They describe some of the best practices used in commit stage like when to break the commit stage, constantly improve the commit stage scripts, give developers ownership and use build master in large teams. They discuss about storing the output of the commit stage in an artifact repository. They describe the principles of the commit test suite and the strategies that can be used to run tests quickly. They also recommend using mocking toolset and discuss an example based on open source mock system called JMock. Thus the establishment of a commit stage launched on every change, that builds binaries, runs automated tests and generates metrics is important to adopt the practice of continuous integration.

The authors discuss the importance of acceptance tests within the deployment pipeline. They describe how acceptance tests are different from unit or component tests, the former being more business focused. In their experience, the cost of creating and maintaining automated acceptance tests is much lower than repetitive manual and regression testing. They also discuss how to implement and maintain effective acceptance tests with code examples. They describe the principles and practices that should be used in the acceptance test stage. They also discuss the benefits of making the delivery team that includes developers and testers, owners of the automated acceptance tests. Lastly, they describe the techniques which can improve the performance of the acceptance test suite.

In this chapter authors discuss nonfunctional requirements specifically capacity testing. They start by discussing the importance of nonfunctional requirements, how to analyze them and how to measure capacity. Then they describe how to create the capacity testing environment to conduct the measurements. They recommend creating a replica of production environments for the applications in which performance is a serious concern. They discuss the strategies for creating capacity tests from the automated acceptance test suite which represent realistic scenarios to obtain comprehensive, maintainable coverage of the system. They recommend adding nonfunctional testing as a separate stage into the deployment pipeline. Lastly, they discuss some additional benefits of using a capacity testing system and call it an invaluable resource.

In this chapter, the authors focus on the differences between deploying the software in a testing environment and releasing it in the production, supported by an interesting example of the test and release process diagram. They have discussed about two effective strategies to ensure zero-downtime releases and rollbacks: blue-green deployments and canary releasing. A critical stress has been put on the suggestion of 'not' subverting the processes in case of emergency fixes. They define that the aggressive approach of directly deploying changes to the production environment in case of an emergency fix might lead to severe consequences like introducing new issue due to the incompatibility of the changes made, and also, the environment might move to unknown state due to unregistered changes and make it impossible to reproduce. Lastly, they refer to few tips and tricks like encouraging the people who are involved in deployment should be involved in creating the deployment process and techniques, every activity should be registered, avoid deleting the old file and rather relocate them. Most importantly, release planning is getting the representatives from every part of your organization involved in the delivery and these people should continue to meet throughout the life of the project and continually work to make the delivery process more efficient.

The authors of the chapter review the first step of deploying software as discussed in Chapter 1 of this book, that is, creating and managing the infrastructure in which the application will run. There are two attributes which describe any environment, first, The hardware configuration of the servers that form the environment (CPUs, amount of memory, spindles, NICs, etc.) and secondly, The configuration of the operating system and middleware (such as messaging systems, application and web servers, database servers) required to support the applications that will run within it. The authors also explain how the needs of the operation team and state that the group or stakeholder management plays an important role in the success of any project. To explain the concept of managing server provisioning and configuration, they have provided various examples and puppet configuration for multiple modules. To deal with problems due to different servers, they have introduced the concept of virtualization and discussed its benefits like fast-response to the changing environment, standardized hardware, ease of managing the baselines, etc. In the end, the authors have mentioned 4 areas of consideration while creating an application monitoring strategy: Instrumenting applications and infrastructure for data collection, data storage for quick and easy retrieval, aggregation of data to make it suitable for the operations, and setting up of notifications.

In this chapter, authors discuss about database management and data setup for testing. They start by discussing the importance of database scripting for database initialization and migration and integrating those scripts with the continuous delivery process. Then they describe the techniques which can help to roll back databases without losing data and how to release with zero-downtime. Next they describe the challenges associated with testing data setup and different approaches that can be used to handle them. Then they discuss the strategies to manage data for different stages of automated testing within the deployment pipeline. In the end they provide list of principles and practices which can be used to handle the issues with data management in automated testing and production environments.

The authors introduce the chapter with the explanation of an important term like componentization and how the abstract use of this term has led to ambiguity around the concept. The major advantage of dividing an application into multiple components is that during the integration of a major functionality into the system, it reduces the chances of introducing new bugs and even if added to the system, only the particular component has to be mended. The authors claim that for a small project it is understandable to have single version control repository, however, a project can expand to a bigger level and that is when need to create discrete component comes in. But, once a project attains a certain threshold it becomes cost inefficient to attempt code componentization. Thumb-rule for a continuous integration process is to keep the application releasable. One of the universally accepted solutions to this is 'version control', however, it is less-efficient and a better approach to obtain a high optimal solution to allow everyone to work on the mainline.

In this chapter, the authors dive into the concept of version control mechanism, discussing from the history to the needs which gave birth to version control. The authors then discuss the in-depth history of version control systems like CVS, Subversion (SVN), and Commercial Version Control Systems (Perfore, AccuRev, BitKeeper). To explain the components of version control, the authors briefly explain the concept of branching and merging. The branching basically facilitates the ability to perform parallel development by different groups or individuals without affecting each other's work. Also, they provide with multiple logical reasons on why different teams may branch the code. Further, they introduce the Distributed Version Control Systems (DVCS), followed by the history and its implementation corporate environment. To clarify DVCS in details, the authors also exemplify the workflow diagram for it. In conclusion, the authors present various options around version control system to ensure an efficient development process, however, an important exercise is to continuously push the developed code bit regularly to the mainline code, minimize the risk.

In the last chapter of the book, the authors primarily focus on the management of a development project. They state that an effective collaboration depends on the stakeholders or people involved and there willingness to bring changes to the project. The authors have presented with four major sections in the chapter to assist in the adaptation of continuous delivery within an organization, namely, maturity model, project lifecycle, risk management and common delivery problems. With respect to the maturity model, the authors believe that organizational change is a tough task but can be achieved if implemented incrementally and impacts are checked regularly. Also, they have discussed in detail that projects could different in nature, but it is possible to filter the common elements from them and generalize a lifecycle for the software delivery. The authors have taken a firm stand on the risk management process and have also provided details on how to perform a risk-management exercise. In the end, they have mentioned symptoms and causes for few common delivery problems like infrequent or buggy deployment, poor application quality, poorly managed continuous integration process, and poor configuration management.

E-BOOK: https://www.safaribooksonline.com/library/view/ continuous-delivery-reliable/9780321670250/

HARDCOVER: https://www.amazon.com/Continuous-Delivery- Deployment-Automation-Addison-Wesley/dp/0321601912