Storage Ring Mode Development Environment

1 Naming conventions

We agreed that, until someone comes up with something better, we will use the following syntax conventions for Git branches:

• lower case
• seperate words with hyphens
• no underscores, no camel case, etc.

Example: "storage-ring-mode"

Note: This is inspired by Git Flow branch naming conventions, since (at the time of writing), there were no other conventions to be found (though a quick search). We thought about whether we want to fully adapt Git Flow branch naming / workflow conventions (e.g. "feature/...", "release/...") in the future for a minute, but decided that we don't have time to do that now.

2 Git Branches and Corresponding Databases

storage-ring-mode	LSA_PROTO@AccDbU	Storage Ring Mode development
master	LSA@AccDbU	"regular" development
int	LSA@AccDbT	pre production testing and / or Storage Ring Mode feature testing
Rxx	LSA@AccDbP	production

3 Integration Environment

There shall be int branches for all projects that shall be used / tested in the integration environment. A build chain shall be created in jenkins to automatically build and deploy them.

Versions numbers shall follow what was specified on the storage-ring-mode / master branches that int branches were merged into from, but presenting the "release candidate" qualifier.

Example: 13.1.0-RC

Be aware that according to this examination, 13.1.0-RC < 13.1.0-SNAPSHOT < 13.1.0, which may not be ideal.

But since there seems to be nothing between 13.1.0-SNAPSHOT and 13.1.0 and "unknown identifiers" (like e.g. "int" or whatever we may consider to choose freely) are 13.1.0 < 13.1.0-whatever, there seems to be no better choice. Also, since we always fully qualify whether we want a release, snapshot or release candidate, we decided that this should not hurt in practice.

4 Branching and Merging

In general, development for Storage Ring Mode shall be done on the storage-ring-mode branches (code-wise) and in lsa-db-scripts/src/main/liqubase/ptype and lsa-db-data-ptype (database-wise). Ideally, once things are ready for testing, they shall be merged into the int branches / lsa-db-data-int, rolled out into the integration environment, be tested and after that, be merged into master.

Merges back from int to master represent fixes for bugs found in integration.