If someone said CD to me a decade ago, I would immediately think of a compact disc or certificate of deposit. As time moved on my MacBook nor car do not have optical disc drives and I have not had a CD with my bank since my last internship at university 15 or so years ago.
Today if someone says CD to you, your mind might race to the conjoined term CI/CD or one of the two software delivery related definitions; Continuous Delivery vs Continuous Deployment. At Harness, we focus on Continuous Delivery but what are the similarities and differences between the two.
When doing your due diligence between the two different taxonomies, you will see that there is a lot of overlap and depending on your source also a lot of difference. Trying to answer the question “do we want to do Continuous Delivery or Deployment” as definitions vary can be a murky one.
The goals of Continuous Deployment and Continuous Delivery are the same to get your ideas out as quickly as possible. Though as you get closer to the public aka production, the amount of decisions and differences that have to be settled to delivery confidently is where Continuous Delivery steps in to orchestrate several systemic and non-systemic items.
A literal definition of a software deployment is to allow your changes to be available. In modern terms, you might be deploying your changes to a container orchestrator or a platform-as-a-service. Most of the time a deployment is incremental changes as you start to build incremental confidence on feature sets that need to be delivered.
Over a decade ago on a project I was working on in the Federal space, we leveraged Rational ClearCase alongside Rational Build Forge. We were building the next generation at the time portal deploying to IBM WebSphere. Because of the size of the application we were working on, our build process would take 30 minutes or so and the deployment to a dev integration environment would take another 20-30 minutes.
At the end of some days before jamming on Interstate 495 to go home, if I felt comfortable on what I locally made I would commit the changes I made to a ClearCase Branch. Once the commit occurred the deployment process to dev integration would be automated. The specific JARs would be built by Build Forge and sent along their way to be packaged into an EAR and deployed to WebSphere.
Because of the time that took, I only committed to a specific or new branch to kick off a build at the end of the day. Today we have certainly trimmed the times to build and deploy an item.
The only check we had if the build literally failed thus your deployment would not be there. A lot of the testing followed after having items in dev integration or migrated to a QA environment.
A definition of continuous deployment is to take the path of least resistance and as quickly as possible, deploy your changes to make them available. This is great especially for lower environments before a lot of rigor is applied. With advancements in code and test coverage, we can implement certain coverages along with the build.
Though for us over a decade ago to actually do a release e.g let the public have access to our changes unless an emergency was once every few months due to all the boxes we had to cross; lots of decisions.
Software does not write itself and everything you see was a decision at some point. Software is not magic and sometimes you might scratch your head why something was written or behaves a certain way, again that was a decision made before your time.
From a safety standpoint with the least number of decisions can be a lower environment. As an engineer, you control your changes until you have to see how they start to behave in different environments marching ever closer to production. As your hard work starts to integrate with other engineers and stakeholders, decision time starts to increase on the changes.
The purpose of the SDLC is a confidence-building exercise. We can build confidence either systemically or human-centric. Systemically we can have solutions that validate our features match the expectation such as test coverage and application performance management tools. With the human element, documenting and approving what has happened with change management tools and notifications such as ChatOps.
Frameworks and processes are in place such as change control or regulatory compliance that we have to live with and perceivable slow the flow of our ideas into the hands of the public. This is where Continuous Delivery comes in.
Continuous Delivery – Learn with Harness
Reaching towards the nirvana of getting all the stakeholders confident in the changes in an automated fashion is Continuous Delivery. Imagine applying for a credit card in the 1990s vs applying for a credit card today. We are used to getting an almost instant decision to start building reward points vs waiting days or weeks in decades gone by.
Continuous Delivery ties everything together from infrastructure, release orchestration, and confidence-building e.g approvals/test coverage/monitoring to deliver a successful release or fail early in the pipeline.
At Harness, we are purpose-built for Continuous Delivery. We are bringing to the world Harness University helping teach those that one size does not fit all in Continuous Delivery and we are all on the journey together. Be on the lookout for other cities as Harness University comes to a city near you!