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:
- 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?