Git Options

gitOptions.md

Git Proposal

This proposed Git workflow aims to remove the bus from daily parlance

Regular Development...

• Create feature/bugfix branches from Master
• (optional) Merge feature(s) into development for Dev testing (auto-deploy)
• Merge features(s) into release-candidate for QA/UAT testing (can be feature branch or dev->release-candidate polyfeature if reasonable)

Regular Releasing...

Developers Tag release from master on GitHub: add release notes (esp. env vars, etc) Replace release-candidate and dev with latest of master (optionally, rebase dev on master if dev is ahead) Create DevOps deploy ticket

DevOps Deploy the tagged release

To omit a feature after it's in Dev you would have to...

• Roll back dev

To omit a feature after it's in QA you would have to...

• Roll back and unlock qa

Details

...into dev

• possibly make a -rb-dev branch, keep original branch
• open pull request
• self or team merge
• auto deploys to Dev env Should we make Dev lockable too?

...into release-candidate

• possibly make -rb-rc branch, keep original branch (can often re-use -rb-dev, or dev itself if clean)
• open pull request
• before someone merges, acquire sacred QA Lock
• auto deploys to QA env

Pros:

• developers maintain velocity by self-merging into dev branch for initial testing (requires reviews for QA/RC merges)
• can straightforwardly drop features after either Dev testing or QA/UAT testing since features are ultimately merged one-by-one into release-candidate
• multiple feature reviews: isolated feature review opportunities into Dev, RC
• comprehensive review: the all-inclusive release-candidate->master PR is reviewed and merged by the developers

Cons:

• less straightforward
• possibility of multiple rebases when in conflict (mitigated by rebasing once and merging upstream in the same order)
• requires developers to track a feature through four (possibly ordered) pull requests before it’s "done" and in production

Laws

release-candidate always ahead or at master qa always ahead or at release-candidate dev always ahead or at release-candidate When merging into master, create a new release-candidate == master, update dev When merging into release-candidate, create a new qa == release-candidate

What is 'QA Lock'?

We will 'lock' QA environment such that it only contains feature/polyfeature at a time. A developer will acquire the lock, merge his work, test, and release the lock.

Detailed flow

1. Developer pull requests his work into release-candidate
2. Technical testing and UAT testing is performed 3b) In case of success, the team will perform regression teating and merge work into master, replace release-candidate and update dev. 3c) In case of failure, the developer will rollback release-candidate.
3. Developer releases QA lock

Orchestration

There will be a Slack channel dedicated to the BAP team's git/deployments in which the QA lock can be managed.