Best-practice for continuous integration and deployment

Question

Continuous integration concept has just been integrated in my team.

Assume we have an integration branch named Dev.

From it derived 3 branches,

Answer 1

Oh boy. You're hitting real world CD problems. Really good questions.

The answer depends a bit on highly tightly coupled the development work is on the various projects.

In my ideal situation for you would be to have a number of "effort" specific test environments. In one case, you could consider a test environment for each project. When there is a completed build of Project A, you push it into Environment A which has the latest approved / production versions for B/C and you can perform basic integration tests there. If they pass, you promote the build to an integration test environment where the latest good A, is deployed along the latest B & C for the same release. When the integration test environment is passing tests, you can promote the contents of it as a release set containing known versions of A, B, & C. That release set would be deployed to any UAT, Staging, or Production environments.

The basic idea is to give each project a degree of isolation so that it can be tested well even if the other projects are (temporarily) badly broken, while getting to full integration tests as quickly as possible. We also want to make sure that whatever we find actually passes integration tests will be promoted together. Picking and choosing project versions to release that haven't been tested together is too risky for my taste.

This is actually a topic I get to talk about quite a lot. If you don't mind, I'll list out a few presentations I've given around these topics.

1) Scaling CI for Parallel Development (co-presented with Chris Lucca of Accurev)

This talks a good about broad strategies for balancing isolation and integration. Much of it assumes the sub-projects are being merged into a common code base, but the principals can be applied to independently built and deployed modules with only a little imagination.

2) Using uDeploy with Jenkins (registration required)

This is more product focused, but shows almost exactly the idea of using an integration test environment for multiple projects, creating a release set (we call it a "snapshot") and promoting that. Our integration with TeamCity is quite similar, but I think the strategy held in there may be more important

3) Slides visualizing a multi-component pipeline:

http://www.slideshare.net/Urbancode/adapting-deployment-pipelines-for-complex-applications