In this video, we will discuss the problems with the typical
software deployment process.
What is continuous deployment?
What is continuous delivery?
And what are the benefits of implementing continuous delivery in
our software development life cycle
Hey friends.
Welcome back to the channel.
If you're new here, my name is Vibhor.
I am an Executive Agile & Leadership Coach based in Toronto, Canada.
And this is the fourth and the last video in an ongoing and very short
video series on continuous integration and continuous deployment, where I have
attempted to simplify the jargon related to the software development and deployment
process for the non-technical members of the team, especially the scrum masters
who do not have a technical background.
You can find a link to the last three videos in this corner.
In the last video, EXSoft, which is our fictitious software consulting company
who are helping us to write the code for our fictitious online bookstore
implemented continuous integration in their software development process.
Let's recap!
Before continuous integration, the three easy soft development teams
with checking in the code into a separate repository, dedicated to each
team on the source control system.
At the end of each sprint, the integration team collected the code
from these different repositories, merged the code and then stored the
merged code into a separate repository called the mainline repository on
the same source control system.
After continuous integration was implemented, all the developers in the
three teams were now required to check small units of their code as soon as they
were written directly into the mainline repository, possibly multiple times a day,
instead of waiting for the sprint to end.
Continuous integration tools like Jenkins, Bamboo, GitLab, et cetera,
helped in constantly checking the mainline repository for changes.
When a change was detected, those tools made the code
pass through a build pipeline.
But hold on.
What is a build pipeline?
You must have heard this term called pipeline tossed around by the
technical savvy members of your team.
A pipeline is nothing but a term used to define a sequence of operations and
the tools that perform those operations.
Similarly, a build pipeline is a sequence of operations and tools to perform...
the build.
The build, as I defined in the previous videos is the term used for the action of
converting the human readable code written in the languages like Java, Python, and
C++ into machine-readable zeros and ones.
The output of the build pipeline is a build that is successful,
or maybe not successful.
The developer who checked in the code and everyone else is notified about the
success or the failure of the build.
If the build was successful the developer, continue working
on the next piece of code.
But if the build was not successful, the developer needs to fix the bill errors
before starting to work on something else.
Let's imagine that the build was successful.
Meaning the code, the small little tiny piece of code successfully passed through
the integration part of the CI/CD puzzle.
It's now time for the operations team to pick the successful
build and perform the deployment.
The operations team deploys the compiled code on various environments.
Environments like test environment, staging environment,
or production environment.
Now, since this video is about continuous delivery, let's zoom into this deployment
part of the whole process and see if there is any scope for improvement.
After the build is successful, the operations team receives the compiled
code along with a list of instructions.
The instructions that the operations team must follow step-by-step to
successfully install the software on different environments.
But here's the problem.
Oftentimes these instructions, since these are written manually are not a
hundred percent accurate leaving room
for misinterpretation, by different members of the operations team who
manage these different environments.
This leads to mistakes, making the deployment process lengthy and prone
to errors, errors like differences in versions of softwares and
libraries on different environments.
For the software to be stable
these versions must be identical on test, staging and production environments.
In case of errors the operations team needs to repeat the entire
deployment process, wiping the different environments clean to delete
any trace of the bad installation.
This leads to slow delivery of the functionality to the end user.
Also because of this, most often the operations team dreads, the manual
deployment process, and usually does not perform the deployment on Fridays.
Well...unless they fancy spending their weekends resolving deployment errors.
Not only that, this is when deployment happens once per sprint.
Imagine with continuous integration in place, the operations team
will require to deploy multiple, possibly hundreds of times
during a single sprint, which can really suck big times.
Alright, now that we know the problems with the typical deployment process, let's
see how these problems can be resolved.
If you followed carefully, you must have noticed that the main
problem with the deployment process is that the process is manual.
So to fix the deployment problems, we need a way to automate the process.
And how do we do that?
We do that by creating an automated pipeline.
A Release Pipeline.
Just like a build pipeline, a release pipeline is also a sequence of
operations to perform the deployment.
In this case, it is a sequence of steps that the operations team
receives as instructions from the development team to deploy the software
on different environments.
These steps are automated with the help of the same tools that helped
us with continuous integration like Jenkins, Bamboo, GitLab, et cetera.
The release pipeline powered by these tools results in the software
getting successfully deployed, first to the test environment where it
goes through some manual or maybe
some automated tests.
Then if the test results are positive, this software is deployed automatically
to the production environment without any explicit approval from the development
team or the product management.
This is called the continuous deployment.
But wait, isn't this, the video about continuous delivery?
Yes, it is.
The "CD" in CI/CD can be continuous delivery or continuous deployment,
depending upon one little nuance, CHOICE!
That's right after the code successfully passes all the tests in the release
pipeline, if the team or the product management practices, it's right to
choose when to deploy to production for marketing or any other reasons, then the
process is called continuous delivery.
And that's what "CD" in CI/CD refers to.
It can still be deployed to the production anytime, but now business
has complete control over when.
Without this choice, the process is called continuous deployment.
And that's what CD in that case, would stand for.
Continuous deployment requires a highly developed culture of
monitoring, being on call, and having the capacity to recover quickly.
However, this kind of culture is difficult to maintain and hence it
is not an option for many companies.
For this reason, in general, when you hear people saying CI/CD, it is safe to assume
that they are referring to continuous delivery and not continuous deployment.
All right, once deployed to the production environment, the software becomes
available to the end user for consumption.
After that, the defects found by the end users, along with the enhancement
requests, if any, are recorded by the operations team who then communicated
those defects and enhancement requests, to the product management or in our
case to the EZSoft product owner with the help of the scrum master, the
product owner converts these requests into small bite-sized user stories.
These user stories are then prioritized and later merged into the existing product
backlog to be picked by the development team to work on in a future sprint.
With continuous delivery in place releasing the software to
production takes less effort.
Also, since now it happens with minimal human involvement using
automated and repeatable pipelines,
the release software is more reliable.
Continuous delivery puts the control back into the hands of the delivery team or
product management who can decide when to release the software into production.
And lastly, we can now release more often, which enables early
feedback for timely improvement.
So there you have it., I hope this little series on continuous integration
and continuous delivery will enable you to have better conversations
with your development team.
If this video and series provided any value to you, then do not forget
to smash that like button subscribe and leave your valuable comments.
I'll see you in the next video.