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

storage-ring-mode-branching-and-merging.png

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.
Topic revision: r3 - 13 Apr 2020, JuttaFitzek
This site is powered by FoswikiCopyright © by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding Foswiki? Send feedback