As discussed in my last post defining and contrasting Continuous Delivery and Deployment, there is a distinction 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.
So, what does one ‘deliver’ when adopting Continuous Delivery (or Deployment)? Lets look at it from a perspective of People, Process and Technology.
People
DevOps, at its core is a cultural movement. The people aspect of devOps is where it all started. When adopting Continuous Delivery, the most important part is the culture of continuous delivery – continuous collaboration between ALL stakeholders who need to be onboard to enable and consume continuous delivery. This includes Dev and Ops (duh!) but also stakeholders across the Software Delivery Lifecycle (SDLC) including, but not limited to, Line of Business Owners, Product owners, Analysts, Architecture and Design, Security, QA and management. It is important to create a culture where all these stakeholders not only contribute to the Continuous Delivery, but also consume the feedback that comes from the Continuous Delivery, at every stage. Dev uses the feedback to determine what to work on for the next Sprint; QA uses it to test and validate functionality, integrations and performance; Ops determines how the environment performed and where it needs enhancement; Project and executive management to manage their project and release plans, and so on.
Above all, by taking on Continuous Delivery, you Continuously Deliver and iterate on culture – a culture of continuous collaboration, communication, trust and working towards common business goals.
Process
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 itself. Deployment of the software is not as simple as copying some binaries over FTP. It involves file transfers, to multiple locations on potentially a complex set of nodes, but also involves configuration changes – to OS, databases and middleware. It also involves an orchestration of steps. One cannot simply do deployment steps in a mechanical linear manner. Middleware processes may need to be restarted after configuration changes. Services may need to be stopped before file transfers and then restarted, all in a coordinated orchestrated manner. 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 process(es). They are tested and proven to work.
Remember, these deployment processes also includes the processes to deploy the environments, not just the applications.
Technology
What does one deploy? As I mentioned in my last post, what one deploys may be anything from simple configuration changes; to incremental code changes towards a new feature; to Database schema changes; to changes to the environment. They all need to be deployed. These require a tool or 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 QA, to Perf, to SIT, UAT and Prod – whatever your environments may be. A tool like IBM UrbanCode Deploy, falls into this space, with its myriad plug-ins for application deployments, middleware configuration, databases and for environment deployments and configuration.
The key here is to start continuous delivery right 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.
Continuously Deploy – from Sprint 0
Last but not the least, let me address the statement I made earlier – deploy right from Sprint 0. What does one deploy in Sprint 0? There is no code yet. That’s easy – you deploy the environment. Get the *nux (or if you really have to, Windows) distribution and install it – somewhere…
Like to learn more about Adopting DevOps? Check out my new book – The DevOps Adoption Playbook.
—
Follow me on Twitter @sd_architect
—
The series so far:
Adopting DevOps:
- Adopting DevOps – Part I: Begin with the Why
- Adopting DevOps – Part II: The Need for Organizational Change
- Adopting DevOps – Part III: Aligning Dev and Ops Teams
- Adopting DevOps – Where to start? (Video blog)
- DevOps vs Outsourcing
Understanding DevOps:
- Understanding DevOps – Part 1: Defining DevOps
- Understanding DevOps – Part 2: Continuous Integration and Continuous Delivery
- Understanding DevOps – Part 3: The Battle of Dev vs Ops
- Understanding DevOps – Part 4: Continuous Testing and Continuous Monitoring
- Understanding DevOps – Part 5: Infrastructure as Code
- Understanding DevOps – Part 6: Continuous Deployment
Home: sdarchitect.blog 
9 Comments Add yours