proposed_development_workflow.md

proposed development workflow for a team of 4-8 people

State

branches

master

• represents last production deploy + any changes currently being deployed within production vpc
• tag represents last deployed version, format v${major}.${minor}.${patch} (format is arbitrary, semver not required. will be determined by the deployment process).
• only production hotfixes and staging should be merged to master.
• prevent history edits

No gated deploy or push. Trigger this at any time because hotfixes sometimes need to be deployed on short notice. This should only be done with extreme caution and should be reviewed by 2+ people.

staging

• default branch, tracks master
• represents last staging deploy + any changes currently being deploy within staging vpc
• feature/bug/task/story branches branch from staging.
• adding commits to staging or chaing the HEAD of staging in github triggers an automated deploy.
• prevent history edits

testing

• just an alternative to staging if you need an isolated environment to test something
• represents last testing deploy + any changes currently being deploy within testing vpc
• feature/bug/task/story branches branch from testing.
• adding commits to testing or chaing the HEAD of testing in github triggers an automated deploy.
• history rewriting allowed. force push your feature branch here to deploy & test it in isolation. git push -f origin my-branch-name:testing

Workflows

I'm working on a feature

1. cool. work on it on your machine, run the tests on your machine against your local database. open a PR when you want it reviewed, or a draft if you don't necessarilly want it reviewed yet.
2. add a link to the fibery item(s) the PR involves to the PR body.
3. creating the PR runs unit tests & integration tests.
4. for each of the test builds, if it fails - just slap something on the PR to notify the author they still have work to do. this requires some github integration but it's been done before.

• each push to the pr with new commits triggers another unit & integration test build.

I want to test my code deployed, but it has not been code reviewed

git push -f origin my-branch-name/testing

1. build server sees this change of HEAD on testing, triggers a deploy
2. if the deploy succedes, post a message to #engineering with the commit hash, the last author, the branch name, and deploy time.
3. if the deploy fails, post a message to #engineering with the commit hash, the last author, and any relevant error summary.

I want to deploy my code to staging that has been code reviewed & approved

1. you have an open pull request that has 2 approvers.
2. you've updated the relevant fibery item(s) to reflect the state Code Reviewed
3. merge it in github to staging. a deploy will be triggered. a unit test build will be triggered. an integration test build will be triggered.
4. if the deploy succedes, post a message to #engineering with the commit hash, the last author, the branch name, and deploy time.
5. if the deploy fails, post a message to #engineering with the commit hash, the last author, and any relevant error summary.
6. for each of the test builds, if it fails - post a message to #engineering with the number of tests failed, the last commit hash, the last author, and a link to the page with a readout of the test failures.
7. once it has been deployed, update the fibery item(s) to state Testing

I want to deploy the latest changes in staging to production (and I have coordindated with the team)

1. create a pull request from staging to master
2. review the changes. if there's anything you don't intend to release, revert commits from staging and reopen pull requests for each merge you've reverted. once you've done this, staging will be in the state you intend to release.
3. ensure all tests are passing. if they aren't, it's up to you to decide to not deploy master, but there isn't a gateway.
4. merge to master. deploy master. deploy tags master with some preselected version that will be selected at deploy. the deploy will either prompt for this or this will be a manual intervention in the form of tagging the last commit in the repo.
5. once it is deployed, update the relevant fibery item(s) to state Done.

I have a hotfix to deploy to master because I totally broke something and it's on fire.

1. create a pull request directly from master.
2. review the changes. 2+ approvers.
3. ensure all tests are passing. if they aren't, it's up to you to decide to not deploy master, but there isn't a gateway. if you deploy before waiting for test failures or ignore test failures and later find out the tests would have caught a bug you've introduced, two slaps on the wrist.
4. merge to master. deploy master. the deploy process tags master with some preselected version that will be selected at deploy. the deploy will either prompt for this or this will be a manual intervention in the form of tagging the last commit in the repo.
5. merge master back to staging so others receive these commits.
6. create / update relevant fibery item(s) to state Done.