Skip to content

Dev Workflow

Jump to bottom
Alec edited this page Oct 22, 2017 · 2 revisions

Dev Workflow:

Quick note, if you change the database in any way (migrations etc, IT MUST BE REVIEWED BEFORE YOU PUSH YOUR BRANCH OR MERGE TO STAGING OR ANYWHERE).

  • You will first START a ticket on pivotal tracker.
  • Now checkout a branch (if the ticket is called As a user I should see hello world), then a good branch name may be feature/display-hello-world. Note the dashes.
  • ALWAYS git fetch origin -a THEN BRANCH FROM origin/master with git checkout origin/master -b (feature, chore or bugfix)/BRANCH NAME Other branches may not be up to date, and the master branch will be behind origin/master unless you reset or push.
  • Now do your work.
  • git add -A to add your new work, and git commit -am MESSAGE to commit.
  • PUSH ONLY TO YOUR BRANCH : git push origin feature/display-hello-world
  • Rebasing is a useful tool: If you are behind master because someone else has done work and merged to master, then you can type git fetch -a && git rebase origin/master while on your branch to "replay" your changes on top of the newest master.
  • Note that rebasing really can mess things up if you have merged your branch to another branch, so ONLY do this if you HAVE NOT MERGED TO ANY OTHER BRANCHES AND HAVENT PUSHED COMMITS TO GITHUB.
  • Otherwise, if you need to have your branch up to date with master, then git fetch -a && git merge origin/master will merge master into your current branch. Note the syntax. its git merge OTHER_BRANCH INTO HERE
  • Now after you push to your branch and the tests pass and everything looks dandy, you can try it out in staging.
  • Checkout staging: git checkout staging
  • I like to keep staging up to date as its always changing, so git fetch origin -a && git reset --hard origin/staging WARNING, THIS WILL DESTROY ANYTHING YOU HAVE IN YOUR CURRENT BRANCH AND OVERWRITE WITH REMOTE STAGING SO MAKE SURE YOU ARE ON THE STAGING BRANCH AND DONT HAVE ANY CHANGES THERE.
  • Okay cool. now we can merge to staging. So git merge feature/display-hello-world Remember the syntax, we are merging display-hello-world into our branch, which is staging.
  • Now git push origin staging to push to staging. Hopefully it passes on semaphore and it will auto deploy! hooray!

Code Review

  • So you have pushed your branch, and hopefully opened a pull request.
  • Click "Finish" in pivotal tracker.
  • What should your pull request be called and what should you write? In pivotal tracker, there is an ID in the ticket.
  • Your pull request title should look like: [#TICKET_ID] Some Message that is relevant
  • Then the description should explain things that arent obvious and any concerns you may have.
  • Then add the label "Review required"
  • Assign a reviewer via the assign area.
  • Once checks pass and that reviewer reviews your code, you should make the changes they suggested.
  • The reviewer removes the review requested label.
  • Now ask for another review. Add back the review requested label.
  • The reviewer now may approve your pull request by "approving" in github, and adding the "Done" label.
  • You now can DELIVER the ticket on pivotal (hit deliver). DO NOT MERGE YOUR CHANGES YET!!!
  • Make sure staging is up to date with your latest code
  • Now, the product owner must review your actual feature (in staging) and can accept or reject your ticket. If they accept it, you may merge your pull request.

AFTER MERGING

  • Open a pull request called [DEPLOY] Production unless one already exists, with the base branch as production and the compare branch as master. Add your pivotal ticket id and a brief description to the description area of this pull request.
  • We can deploy when we feel neccessary, make sure the team knows when we are deploying. When master gets merged to production, semaphore builds the branch and deploys automatically.

SERVERS AND STUFF::

There are multiple important branches: master, production, staging

Production:

ALWAYS PROTECTED, must go through full review process and must only go through your-branch -> master -> production, with steps between. This is the users branch, dont mess up ANYTHING here. Merging to this branch auto deploys to prod.

Master:

This branch should always only have good code that is reviewed and well tested. This branch is a holder for our deploy requests to production and has good code only.

Staging

This is where you can merge your pull requests to test code in a "production-like" environment. If you break this, so be it, but dont break it if you can avoid it.

Feature or bugfix or chore branches

These are your branches, one per pivotal ticket, to mess around in and make the code work, no one cares if you break stuff in your own branch, just dont let it hit shared branches./

Clone this wiki locally