☕Repos

The base code of Leclerc's platform is hosted on BitBucket, with restricted access (LuckyCycle's employees only).

BOL: https://bitbucket.org/luckycycledev/backofficeleclerc/src/master/

FOL: https://bitbucket.org/luckycycledev/frontendleclerc/src/master/

---

Versioning

Each release should be 'tagged' as follow:

X.Y.Z for production releases
X.Y.ZrcA for staging releases (with 'rc' being the staging sub-release)

Any production release should be increased on deploy:

1.0.0 --> 1.0.1

Intermediate releases (tested in the staging environment) should have an additional 'rc' ID:

Production is on version 1.0.1 --> next staging version will be 1.0.2rc1

Consecutive staging release should increment the 'rc' tag, but not the version number:

1.0.2rc1 --> 1.0.2rc2 --> 1.0.2rc3

Once a release is validated for production, the 'rc' part should be stripped of the last staging image, and then deployed in production:

1.0.2rc3 --> 1.0.2 --> deploy (production)

Next release will then be:

1.0.3rc1 (staging) and 1.0.3 (production)

---

Branches

Work should be done on the develop branch.

The master branch, should be only used for production releases.

This allows for quick fixes on the production app, without having to deploy work in progress on the develop branch, but implies to do a pull request from the develop branch to the master one.

Please note that, in a case of a fix, a git rebase origin/master command (as shown below) has to be used in the develop branch to make sure the fix will still be available on the next releases.

git checkout develop (if not on the develop branch already)
git fetch
git rebase origin/master
[ if no conflicts, skip to "git push" (last line) ]
[ else fix conflicts that may occurs, then: ]
git add .
git rebase --continue
git push --force-with-lease origin HEAD

Pull request

When you are ready with a release, you can make a pull request from develop to master. Go to the "pull requests" menu and click on "Create pull request". Select the source branch (should be develop) and destination branch (should be master), enter your description and submit.

You can (and should) review your changes before actually merging.

Once you merged, don't forget to add your tag on this "commit" to be able to deploy it!