The development procedure at Copernica
At Copernica we have split up the development process in a number of steps to ensure that all things we do are well tested before they reach the production phase. The work has essentially been split up in the following steps:
- Create a branche of the Copernica source code
- Development inside this branche
- Code review
- Merge branche back the project code to the main source code
- Code freeze and release to beta
- Release to production
The different steps in the procedure are all taken by different developers, so that all code is reviewed by multiple developers and also tested by different users.
Splitting up the development process however also brings the risk that developers do not take full responsibility - because they trust others to fix things later on. The initial developer could for example choose not to test every thinkable situation, because he assumes that the code will be reviewed and tested by a colleague anyway. Or someone later in the procedure trusts the code to be already perfect because he assumes that it has been tested and reviewed a couple of times before.
To overcome this, we expect from every developer that they take full responsibility. A developer simply has a problem if he passes on a project to a colleague for code review or testing, and this colleague then finds errors or bugs in it. At the end of every step we expect the code to be good enough to be brought to production right away - even though someone else will still review and test it.
With this in mind I will go a little more into detail for the different steps.
When I do not agree with the code (which always is a big shame for the development team) - I send the project back to them to fix it. When the code passes the review, the project is handed over to a tester to actually test all changes and to merge the project code back into the master Copernica code base.
If testing does not show any errors, the code is merged back into the master Copernica code base. At this point, the project is finished and ready to go to production (although it may take some additional weeks before it finally reaches the end users).
After the code freeze, we assign a team to find out all the differences between the previous code freeze and the new code freeze, and run tests to check if things still work as expected. If they do find errors (which you will understand is a HUGE shame for the initial developers and testers as the code had already passed development, code review and testing and was merged back to the master code base) - they will notify the original developers to fix things as soon as possible. If it is not possible to fix things easily, the whole project is removed from the code freeze.
After the code freeze has been tested, we bring out the beta release. This is a special Copernica version used internally by Copernica and by a number of selected customers to see if the code does what we expect from it.