Continuous integration policy problems

Question

Currently our model, with respect to SVN and automated build, looks like

Which, as far as I know, wasn't the way SVN was meant to be used. But the process works okay from a technical standpoint. The goal is to be able to run these chains in parallel, with different people working on new features, others fixing new bugs and regressions, and somehow responding to client feedback.

The difficulty comes in explaining it, even to people who have been around for a while, and usually after someone messes it up and changes one of these steps to something that makes more sense to them (ie using the latest release build for internal testing and sending archived releases to client QA).

I didn't set the policy but I understand what it is, so I'm one of the people who has to explain/maintain it. Having done so many times over the last year, it seems like it doesn't meet the principle of least astonishment.

How could we make this process more obvious/boring?

Answer 1

I'll try keep my answer focused on the

How could we make this process more obvious?

part of the question you asked. Simpler processes do tend to get a "that's obvious" response from users, but are difficult to articulate and develop.

Some things I don't see in the diagram or don't know if they exist in your documentation;

• How code changes flow through the process w.r.t. the repository. We use SVN, but we've modelled a lot of our internal code flows on the git flow with a lot of success. I'm not advocating a change in repository or a work flow for you, but there a number of neat ideas on how to document your code flows and where each build needs to come from in the codebase.
• That said, a change in your code workflows may help. Depending on your specific time and other physical constraints, performing the internal test and QA cycle before the client cycles should help. The artefacts of your internal cycles will then be the inputs to the clients' cycles. These can still be run in parallel, being that they can be physically worked on at the same time. But they wouldn't be parallel, in that what is produced in one will only be available later to the other - as you pretty mush have it now. I think this will be a trade off between your resources, time and unique business and technology issues. I can think of scenarios where both would work.

Further process changes;

• Simplify the documentation, even if it is just to reduce the volume of it. Part of the problem here will be user education. Making it easier for people to understand and use the process properly will reduce the burden on you.
• Short definitive lists of the artefacts from each stage, these can be used as check-lists for conformance and query resolution.
• Define as clearly as possible the parallel chains of the process and the separation between them. How does information (and code) flow between them, if at all? What is the difference between the two acceptance phases at the end of each of them? And so on.
• Define useful "reset" points; if any step fails does the process go back to the previous step or the beginning of the process or are the better more meaningful points to return to, fix and continue. Define how those fixes get back to dev.

Producing a process that is simple and intuitive is hard, changing it in place is even harder. In general, removing un-needed, confusing or unintuitive steps is better to changing them, and even that is better than adding anything.

I believe it was Antoine de Saint-Exupéry that originally said (it has repeated in several forms over the years);

It seems that perfection is attained not when there is nothing more to add, but when there is nothing more to remove.

From wikiquote

Answer 2

Doesn't seem so bad all in all.

Ok, so you want feature branches in your repository workflow. Simple:

Where it says 'release build', you need to make a tag with the appropriate version number and use that to build the releases. It allows you to respond to feedback from Integration and QA testing by applying changes to the tag (and passing the changes back to dev for a future fix)

Where it says "dev" you need a branch per feature. These are the builds that go through internal testing, when they are passed they get merged onto trunk. Once merged, the branch gets deleted (any fixes that you find after this must be fixed as new dev branches or you'll get into a pickle given your overall process).

I don't think that's so hard all in all. Basically the arrows pointing from the Repository to Integration box should become many arrows, one for each branch or tag that you have. Then you have parallel development and the problem becomes one of managing all the different builds and configuration that goes with them... but that's a different story.