DevOps - Adopting Continuous Deployment

Continuous Delivery and Deployment, there is a difference between the two. When adopting DevOps, Continuous Delivery is a core capability to adopt. Continuous Deployment to Production is an optional capability that you may or may not adopt, based on your needs and constraints.

Then what does one do ‘deliver’ when adopting Continuous Delivery or Deployment? We shall look at it from the perspective of  People, Process and Technology.

As mentioned in my previous blog, DevOps is a cultural movement. The people aspect of DevOps is where it all begins. While adopting Continuous Delivery, the most important part is the culture of continuous delivery and continuous collaboration between all the stakeholders who need to be onboard to enable and consume continuous delivery. This includes Dev and Ops but also stakeholders across the SDLC including Business, Analysts, Product owners, Architects and Design, Information Security, Quality Assurance and Management. There is importance of  creating a culture where all these stakeholders contribute to the continuous delivery, and also accept the feedback that comes from the continuous delivery at every stage. Dev teams uses the feedback to decide what to work on for the next Sprint, Quality Assurance or testing teams uses it to test and validate functionality, integrations and performance. The Ops team determines how the environment performed and where it needs enhancement or corrections. Project management team will manage their project and release plans, and so on.

The change in culture is of continuous collaboration, communication, trust and working towards common business goals.

When continuously delivering software, one is not only validating the functionality and performance of the software being delivered and the environments it is being delivered to, but also the process of deploying the software. Deployment of the code involves code deployment, file transfers, configuration changes to operating systems, databases and middleware (SOA / OSB, ODI etc). It also involves an orchestration of steps. The middleware processes may need to be restarted after configuration changes. Services may need to be stopped before file transfers and then restarted. Hence, continuous delivery allows for these processes to be tested and refined to ensure that when it comes to the final deployment to production, it is not the first time the team is executing the processes. They are tested and proven to work in production like environments.

Deployment requires set of tools that can automate the deployments and ensure continuous delivery of all changes from one environment in the SDLC to the next – to Dev, to testing, to Performance testing, to SIT integration testing, UAT user acceptance, Pre Prod and Production.

The key here is to start continuous delivery from the start of the project, from Sprint 0 all the way thru the project. In the beginning, the deployments may be simple, to much more complex orchestrated deployments later in the project. Continuous delivering changes – application, middleware, configuration, data and environment – in small pieces, using the right automation tools, reduces risk by validating the automation, the deployment processes, the configuration changes, the environments being deployed to and of course, the application being deployed.