5.3 Ase
5.3 Ase
• Continuous Delivery just means that you are able to do frequent deployments but
may choose not to do it, usually due to businesses preferring a slower rate of
deployment. In order to do Continuous Deployment you must be doing Continuous
Delivery.
• Continuous Deployment means that every change goes through the pipeline and
automatically gets put into production, resulting in many production deployments
every day.
Continuous Delivery
• It aims to build, test and release software faster and more frequently.
• It reduces the cost, time, and risk of delivering changes by allowing for
• One of the first steps in the pipeline is to create binaries and installers.
• The rest of the pipeline runs a series of tests on the binaries to prove that they can be
released.
• Each test that the release candidate passes gives us more confidence that this
particular combination of binary code, configuration information, environment, and
data will work.
• Find ways to reduce cycle time :-- the time it takes from deciding to
make a change, whether a bugfix or a feature, to having it available to
users.
• Delivering fast is also important because it allows you to verify whether
your features and bug fixes really are useful.
• In order to achieve these goals—low cycle time and high quality—we need to make
• Automated:- If the build, deploy, test, and release process is not automated, it is not
software, the configuration of the system, the environments, and the release process.
Since the steps are manual, they are error-prone, and there is no way to review exactly
significantly reduces the risk associated with releasing and makes it much easier
• Feedback is essential to frequent, automated releases. There are three criteria for
feedback to be useful.
3. The delivery team must receive feedback and then act on it.
1. Every Change Should Trigger the Feedback Process
• A working software application can be usefully decomposed into four components: executable
code, configuration, host environment, and data.
• If any of them changes, it can lead to a change in the behavior of the application. Therefore we
need to keep all four of these components under control and ensure that a change in any one of
them is verified.
• If you have manual processes, you are dependent on people to get the job done. People take
longer, they introduce errors, and they are not auditable. Moreover performing manual build, test,
• If people in these roles do not work together on a day-to-day basis, it is essential that they
software.
• Iterative processes help this kind of activity—at least once per iteration a retrospective meeting is held
where everybody discusses how to improve the delivery process for the next iteration.
• Being able to react to feedback also means broadcasting information. Using big,
mechanisms is central to ensuring that feedback is fed-back and makes the final
• Finally, feedback is no good unless it is acted upon. This requires discipline and
planning.
• When something needs doing, it is the responsibility of the whole team to stop what
they are doing and decide on a course of action. Only once this is done should the
• It should be easy because you have tested every single part of the release
process hundreds of times before.
• The repeatability and reliability derive from two principles: automate almost
everything, and keep everything you need to build, deploy, test, and release
your application in version control.
• Deploying software ultimately involves three things:
• Most development teams don’t automate their release process because it seems
such a daunting task.
• It’s easier just to do things manually. Perhaps that is true the first time they
perform a step in the process, but it is certainly not true by the time they perform
that step for the tenth time.
• Everything you need to build, deploy, test, and release your application should be kept in some
form of versioned storage.
• This includes requirement documents, test scripts, automated test cases, network configuration
scripts, deployment scripts, database creation, upgrade, downgrade, and initialization scripts,
application stack configuration scripts, libraries, toolchains, technical documentation, and so on.
• All of this stuff should be version-controlled, and the relevant version should be identifiable for
any given build.
• That is, these change sets should have a single identifier, such as a build number or a version
control change set number, that references every piece.
4. If It Hurts, Do It More Frequently, and Bring the Pain Forward
• Integration is often a very painful process. If this is true on your project, integrate every time
somebody checks in, and do it from the start of the project.
• If testing is a painful process that occurs just before release, don’t do it at the end. Instead, do it
continually from the beginning of the project.
• If releasing software is painful, aim to release it every time somebody checks in a change that
passes all the automated tests.
• If you can’t release it to real users upon every change, release it to a production-like environment
upon every check-in.
• “Build quality in” “Bring the pain forward” --catch defects as early in the delivery process as
possible and the next step is to fix them.
• Delivery teams must be disciplined about fixing defects as soon as they are found. (Eg:- A
fire alarm is useless if everybody ignores it.)
• For some agile delivery teams, “done” means released into production. This is the ideal
situation for a software development project.
• There is no “80% done.” Things are either done, or they are not.
7. Everybody Is Responsible for the Delivery Process
• It is worth emphasizing that the first release of an application is just the first stage in its life.
• All applications evolve, and more releases will follow. It is important that your delivery process
also evolves with it.
• The whole team should regularly gather together and hold a retrospective on the delivery process.
• This means that the team should reflect on what has gone well and what has gone badly, and
discuss ideas on how to improve things.
• Somebody should be nominated to own each idea and ensure that it is acted upon.Then, the next
time that the team gathers, they should report back on what happened.