Would This Workflow Work For a Distributed Team With CI/CD

Question

Because the reaction of @DanCornilescu I understood that my question was not clear. That is why I edited the question heavily.

---

I was brought in on a project where there was only one developer. All development was just done on trunk. But they want to change things:

• They want to work with different developers from all over the world. And it is important those developers can start 'immediately'.
• They want to work with Continuous Integration and Continuous Delivery.
• They want to start using DevOps.
• They use subversion and want to keep using it.

And a few other things, but that is not important here.

Because it was until now a one-man show there are a few problems:

• There are a lot of manual tweaks to get an new version tested, accepted and deployed.
• There are not enough unit and integration tests.

It is my job to design a new workflow, but this is the first time I am asked to do this kind of job. I have a first idea for a workflow, but it would be good if people with experience could tell me what could be tweaked and what is wrong.

At the moment there are no peer reviews. I want to change that, but in case that is not going to happen I defined a workflow for two types of developers: trusted and mentored.

I came up with the following for a trusted developer:

White text describes manual steps, blue text describes automated steps.

• Every developer has his own branch and does his development on this branch. (This is my preferred way and in my research I saw this also recommended. But I also saw often that svn users did not like to do this. Especially on the long term I think this would bear more fruit. Or am I overestimating the difference?)
• At least every morning before a developer starts working he merges trunk into his branch.
• Normal work should be checked in the same days as it is started. For work that takes longer a special branch should be created. This branch should also have trunk merged into it at least at the start of the workday.
• Every-time the developer has added something that can be tested, he should run the unit tests. Before running the unit tests an automatic merge is done. If this results in conflicts those have to be solved.
• When the developer thinks he has something that can be committed he calls the unit tests with a commit flag. When everything is OK the commit and follow-up actions are executed.
• A pre-hook is defined that checks that the merge and unit tests where successful.
• After the commit is done successfully a post-hook will create an integration server where the above tests are run again and integration tests are performed. When it is not a special branch: on success an acceptation server is created with this branch and the branch is merged (--reintegrate) into trunk. The developer is always notified of the result.
• A developer is only allowed to go home when his version is successfully committed. Ideally it should also pass the integration tests. (This sounds a bit harsh, but I added this because I have seen developers not committing for weeks because they had not changed much yet. With all the merge problems this created.)

There is a slight difference flow for a mentored developer:

When a mentored developer does a successful commit the branch is not merged into trunk, but a message is send to evaluate this branch. When the evaluation is positive the activities from unit testing with commit flag for a trusted developer are (automatically) followed. It would be opportune if those reviews would be done as soon as possible, to circumvent merge conflicts as much as possible.

---

Above is the most important part, but I also want to define the following rules for every developer:

• Only complete workspaces are committed.
• A commit has a single purpose: fix a bug, adds a new feature, …
• When a log message is more as one line, the message starts with a brief of the message, then a blank line and then the message itself.
• Enter the corresponding issue(s) in the log message.
• Lines of a log message are not longer as 72 characters.
• When writing new code, always first write the unit tests.

Would this be a feasible way to work, or are there pitfalls? Can it be optimised?

Answer 1

I've seen attempts to segregate workflows based on user experience/trust/risk evaluations, with questionable results:

• everyone makes mistakes
• the more seasoned developers usually tackle significantly more difficult/complex problems than the mentored developers, often with higher chances of causing regressions

I wouldn't recommend extending the workflow segregation past the code review phase - IMHO once the code passes review it should follow the same pre-commit verification and integration workflow (ideally automated) regardless of the submitter's identity.

Personally I believe a much better approach would be to use a gating CI system which would automatically:

• take the reviewed changes through all the configured pre-commit verifications (whatever those are, ideally including the integration testing)
• reject (return for re-consideration) those which cause regressions or encounter merge conflicts with other changes already in the pipeline
• commit the successfully verified ones
• always keep the integration branch green/passing all the configured pre-commit verification criteria. This is possible because of the orchestrated centralized verifications (the private verifications you mention cannot protect the integration branch from breakages, see https://devops.stackexchange.com/a/512/47)

With such system the responsibility for branch breakages no longer sits with the developers - the automated system should prevent them. No more blame, no more "developers should no go home before..." rules. And without breakages the integration branch development speed is a lot higher - no more stops.

Update:

The updated description shows even more clearly that what you're describing is not CI, I'll try to explain the problems you'll be running into.

In CI the quality verifications are performed on the code exactly as it appears (or will appear) in the integration branch, which means either already merged and committed (or just patched on the tip of the branch together with all other changes that will be committed). This ensures that the verification results are the ones from the actual integration branch.

Your verifications are NOT giving that. Your unit and integration tests are done on the individual code changes prior to their merge and commit into the integration branch, with no orchestration preventing other developers' code changes from being verified in the same time. What you're testing is yesterday's branch plus the individual change, not how the branch will look when the individual change will end up being committed.

Nothing is stopping a particular day's individual changes from interfering with each-other (which is possible even if the changes don't touch the same file, see the example in the post I referenced above). If such interference occurs you have no "official/central" way of finding out about it and informing the developers, they will each learn about if the next day, after merging the trunk (thus picking up the resulting breakage) and seeing their own verification failing for reasons unrelated to their own changes. Now the entire team is blocked - they can't even work in isolation, they have no good label/baseline to use. The breakage needs to be investigated and a fix found and committed - who's responsibility is that? Eventually someone's change will be blamed, despite passing the (isolated) verification! Quite frustrating. These may be rare events in small teams, but in large teams they can be happening often enough to completely collapse the branch's development - I've seen it happening.