Development methodology

Goals

• Stable production environment - development can introduce inadvertent bugs. Development of new feature should not interfere with production.
• Enabling parallel development - features developed in parallel (by one or more people) should not interfere with one another during the development phase. It should follow that two or more developers can work on the same project without interfering with one another's work.
• Minimizing bug damage - letting the code pass through more environments and be seen by more eyes increases the chances of it getting caught and not harming user data.

Tools

Development environments

There are three types of environments:

• Local - local installations of Ymap on developer's machines, not subject to any regulation.
• QC/integration - a prepared Ymap installation on a remote server, which should mimic the production environment as closely as possible.
• Production - the public Ymap installation, can only be updated during version deployment and by hotfixes.

Git branches

• master - the production branch, from which the production environment is derived.
• dev - the development branch, from which QC/integration environment.

Workflow

During development, there may be three types of assignments:

• Regular minor bug fix - commit directly on dev, test locally.
• New feature - create a branch from dev's head, and work on that. When finished, if the dev branch was updated, merge the dev branch into the feature branch, and test. If the testing passed (or the dev branch was not updated), merge into dev. Perform sanity tests in the QC environment.
• Hotfix (a major bug found in the production environment) - fix on master, test on QC, back-merge into development.

When enough features were collected for a version release:

1. Freeze development - no new feature branches should be merged into dev.
2. Update the QC environment to the dev branch, and thoroughly test every feature. Testing should be done by all developers, and preferably some non-devs, too. All bugs and other issues should be collected (but not all should necessarily be fixed).
3. Once all bugs are fixed and the version is ready, tag it in git and merge into master.
4. Deploy the master branch in the production environment.
5. Perform sanity tests on the production environment.

IMPORTANT: deployment to production should ONLY be done at the start of the week. It will never go smoothly, so better have the week available to handle any issues. For the same reason, big testing cycles should also start at the beginning of the week. Exercise caution with hotfixes.