The idea with CD is to create as short a feedback loop as possible. From the idea to the hands of the users. Feedback will then trigger new ideas. Two of the major problems with bad performance in development are:

• The whispering game between human beings
• Blame games when something went wrong

Do empower the ones that build the product. The engineers. They take responsibility from writing the code to making it work in production. So what about for example the operations personnel? They are still extremely necessary. But instead of having the application up and running they should provide the engineers with tools and expertise in infrastructure questions. Engineers ask for help when they need it. Operations is just one type of resource out of many, such as the managers, QAs, architects, etc...

It is important that everyone independent of their profession have a clear view of what is happening. Metrics should be visualized for everyone. Metrics include:

• Code metrics. Code coverage, code complexity, technical dept, etc.
• Production metrics. CPU load, page views, active users, http errors, etc.
• Business metrics. Is the company making money?

CD makes motivated employees. To get a fast response of what you are doing is amazingly effective. Also, mastering your own time has been proven to have a very big impact on how to keep us motivated.

The first thing engineers need to master in order to do CD is TDD. Many companies doing CD agree with that. Why? - Code that is going into the version control system (with Continuous Deployment) directly will be deployed to production. Therefore it must be tested as early as possible. With TDD you write the test before the code, running the tests locally and when they pass the test the (reviewed) code goes into the VCS.

So, having good quality early is one big benefit. Fewer bugs. Automated tests that cheaply can be executed to constantly verify quality.

Another big advantage is the ease of maintaining the code. Engineers do not have to split into teams to handle their code. An engineer writes the code (with attached tests) that is easy to maintain both for herself and for anyone else.

A deeper explanation of TDD can be found at Wikipedia. Note: Although it is good to understand the principles of TDD you must practice it to fully understand its strengths. Developers being used to doing TDD usually never want to go back to not doing it.

The Deployment Pipeline (DP) is a way to move all of the manual steps in the build, test and deploy process in to an automated assembly line. Previously teams who were getting close to a release had a manual regression-phase for days or weeks. After that it was past another week or two before it was dedicated and ready for planning and exercising for the production release.

With the DP all of these manual steps are converted into various kinds of coded tests and installation scripts. All manual steps are checked in to VCS and can automatically be executed several times a day. This is usually done after every code change.

The DP not only removes the need for boring manual tests and release plan meetings. It also makes the whole delivery process much safer. A DP is of course a must in order to do Continuous Delivery. Requiring manual installations several times a day is not an option.

The video clip (only 2 min) is a great illustration of the Deployment Pipeline.

Continuous Integration

Continuous Integration (CI) is mainly about improving the ability for engineers to collaborate in the same codebase.

The Key practices are

• Maintain a Single Source Repository
• Automate the Build
• Make Your Build Self-Testing
• Everyone Commits To the Mainline Every Day
• Every Commit Should Build the Mainline on an Integration Machine
• Keep the Build Fast
• Test in a Clone of the Production Environment
• Make it Easy for Anyone to Get the Latest Executable
• Everyone can see what's happening
• Automate Deployment

For a more detailed explanation of CI please read Martin Fowlers article about CI. It is really good so I won't replicate it all here.

Configuration Management

Configuration Management (CM) is in short to version everything. All of the stuff that is software should be stored in a single version control. Software including for example:

• Application code
• Automated tests
• Database scripts
• Deployment scripts
• Operating system
• Firewall configurations
• ...and more

If your server is burned down you should be able to get a new installation up and running by:

1. Physically installing it into the rack
2. Plug in the power
3. Plug in the network cable
4. Push the hardware On button
5. Push the software Deploy button

Steps 1 to 4 is often completed in an hour or two. But if the last step takes days or weeks it is caused by bad CM.

When working with Continuous Integration you are committing to the main line every single day. That might not seem to be a good idea if the new feature might need weeks or months to be completed. In these cases Feature Toggle (FT) or Branch By Abstraction (BBA) could be used.

With FT or BBA you apply a condition into your code that initially hides the ongoing work of the new feature. This condition could be as simple as an if/else statement. When the new feature is ready the statement is removed for all or at first for just a selection of all users.

In the video clip Martin Fowler and Mike Manson are discussing why you should avoid feature branches and instead focus on collaborating on the main line (trunk, master) in the VCS.

A/B tests

A/B testing is a technique about gathering feedback from real users. It is commonly used in web development, online marketing, and other forms of advertising to do experiments with two variants (A and B). A is the current version in production. The B version includes a change that hopefully provides more value. So the A/B test is an experiment to verify a hypothesis. If B turns out to be the better it probably replaces the current A version.

One simple example of an A/B test is changing the color of the buy-button or moving it from the bottom to the top of the page. The hypothesis could have been: I think more people will click on the buy-button if it is placed at the top right of the page.

Always On

Most systems can afford a downtime for about 1 hour 4 times a year. So if you are deploying a new version to production every quarter most customers won't even notice it.

With Continuous Delivery and deployments as regular as daily, downtime is not an option. To run many parallel web servers with different versions of the software is usually no problem. But if the hosted application for example relies on permanent data in a relational database, the scaling possibilities are much harder. But they are definitely possible!

At first be sure you are versioning your database scripts. Preferably this is done with some versioning tool for databases. See for example Liquibase, RoundhousE or Flyway. Next be sure your incremental changes to the database schema are backward/forward compatible. That means you can run two different versions of the application against the same database schema.