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
• Testing
• 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.

The initial development is normally done by a one or two developers, sometimes with the help of a designer. It is up to them to build the new feature, fix the bug or make the change that is required. The development team is responsible for everything: the project is only ready for code review if they are convinced that it is also good enough to go to production. This means that they have tested all changes, that test scripts were written and that all texts and documentation is up to date too. The changelog and releasenotes are updated and all code is formatted according to the Copernica guidelines.

After the development team has finished the project, the code is reviewed by me. I check if I agree with the chosen algorithms and technologies, and if the code indeed conforms the guidelines. During this phase, no code will be executed because I do not have enough time to do this all by myself. However, I do want to see all changes to be fully aware what happens to the software.

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.

A developer other than the ones who originally started the project will then review and fully test all changes that were made. His one and only objective is to break the code. The code is carefully reviewed, test scripts are executed, extra tests are sometimes created to try to show that the code from the initial developer(s) was wrong. All links created in the project are clicked, all forms are tested and checked for ease-of-use. All texts are checked for spelling errors and understandability, et cetera. If anything fails, the project is directly sent back to the initial developers to fix it, at which point the procedure starts over and goes back to the first development phase.

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).

Once in a while we make a code freeze of the master code base. This happens once every one or two weeks. The code freeze normally contains multiple finished projects that were merged back in the master branche since the previous freeze.

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.

When we see that the beta environment runs correctly for a while, we also bring it to production so that all customers can use the new features. This completes the development procedure.