[bitherd]

We "Feature branch." With a twist on some of the busier repositories. We have a repository per application. We use Subversion (VisualSVN the Windows port)

1. Branch current live revision from Release to branches/ticket-ref (Our Release is what others may call main, trunk or master)

2. Work on feature.

3. Code review.

4. Merge to Release, CI (Jenkins) picks up change and builds NuGet package(s) pushes them to Octopus Deploy

5. Deploy into Test environment

6. QA pass/reject

7. If reject go back to 2.

8. If pass Deploy to production (single click in Octopus Deploy)

9. The twist for busy repositories with lots of changes: Cherry-pick merge to a Stable branch, which CI builds and pushes to Octopus Deploy Live channel

10. Deploy to production

Biggest issue we have is concurrent features x y z all being worked on, x y z are all deployed in test environment, y is passed by QA but can't be deployed because that versioned package also contains x which is rejected, so has to wait until x is fixed, which will then of course contain z. This is only really a problem when we want to get an emergency hotfix w into production. Right now we have to revert x y z from the Release branch, merge w build and deploy then put x y z back in.

This has taken 2 years to perfect so far. Changes we are considering:

a) Jenkins plugin that automatically creates a build configuration the moment you create a feature branch in SVN, this way we can keep x y z in separate versioned packages (I personally feel this is not true "integration" because you are keeping things separate.

b) Feature switches. So if y is good but x and z are not ready we just deploy with those features switched off.

We deploy on Tuesday/Wednesday/Thursday most weeks, never Friday - Monday.