Disclaimer

Projects are different

• Technical requirements
• Business requirements
• Length
• Budget
• Load
• etc

Teams are different

• Level
• Size
• Structure
• etc

There is no silver bullet

• Worked for us != will work for you
• Adopt patterns and principles rather than the full process

CI Workflow (Build Pipeline)

• The build pipeline is split into stages

• Confidence is improved in each stage

• Think of it as a production line on a factory

• Each stage has it`s own purpose

• If succeeds - GREEN light, not - RED light

• "Crucially, if the build fails, the development team stops whatever they are doing and fixes the problem immediately" Jez Humble, p.55

Ultimately, it will look like this...

Each component should have own separate build pipeline

Pipeline Practices

• Build once, deploy many 
• Deploy the same way to every environment
• Fail fast ("If it hurts, do it more frequently")
• Smoke Test Deployments
• Deploy into a copy of Production
• Each change should propagate instantly
• If any part fails, stop the line
• Treat every version as a release candidate

Continuous Delivery

• A set of practices and principles aimed at building, testing, and releasing software faster and more frequently
• Superset of continuous integration, test automation, executable building and production deployment
• Continuous delivery enables frequent deployments while continuous deployment means that every change goes through the pipeline and gets deployed

By having frequent releases for clients, we are getting faster feedback and eventually we are building the right thing

And it follows one the principles of Agile Manifesto

Branching Strategies

...or make it simpler

But there is a problem...

•  with Feature branches - code in feature branch is not integrated with other code, even if regularly merge with master

• with Develop, Release, Prod branches - in most case scenarios it is redundant

Solution

• Avoid using any branches
• All commits go to master, even if feature is not done yet
• If feature is not done, then use Feature Toggles or Branch By Abstraction

Releasing a Feature in CI/CD

1. Developer creates Feature branch from master or develop branch

Releasing a Feature in CI/CD

3. When developer finishes feature

• Portable containers
• Save resources on QA environments
• Isolated from other containers
• Easy distribution of ready-made containers

Add Docker to it

How it looks like in CI Tools

FYI - In different CI tools build stages can be called differently:

• In Jenkins - "job"
• In TeamCity - "build" or "build configuration"
• In Bamboo - "job" or "task"

Jenkins

Jenkins

Jenkins

Build Pipeline Plugin 

TeamCity

Build Configuration

TeamCity

Build Chain

Bamboo

Bamboo

Bamboo