Skip to content

Instantly share code, notes, and snippets.

@amitpatelx

amitpatelx/README.md

Last active September 23, 2018 20:30
Show Gist options
  • Save amitpatelx/877e1e382731d1cf8b1cffd1786aead8 to your computer and use it in GitHub Desktop.
Save amitpatelx/877e1e382731d1cf8b1cffd1786aead8 to your computer and use it in GitHub Desktop.
Download ZIP
Development and Deployment Processes
Raw
README.md

This page outlines about practices we are following related to development and deployment

Branches

  1. Unless mentioned in issue or verbally, create all branches from develop branch.
  2. Pull latest changes from the parent branch before creating a branch from it.
  3. Branch name should be self-explanatory about the issue you are working on(Trello Card). It is highly discouraged to use an abbreviation, issue number etc in branch names.
  4. Avoid creating nested branches from working branches. Do proper planning before start coding.

Naming the branch

  1. All enhacements and feature branches should start with feature/ eg. feature/google-oauth-integration which will be created from develop only.
  2. All the fixes to unreleased code should have branch name fix/ eg., fix/unclickable-signup-button and eventually merged in develop
  3. Create release branch with prefix release/ from develop. This branch will be merged into master
  4. Hotfix(production fix) branch must have name hotfix. There must be always one hotfix branch at a time and merged to master branch.
  5. master branch will be in sync with production server.

Commits

  1. Implement functionality in small commits. If you have done the analysis properly, you would be able to do that naturally.
  2. Review changes you are add and commit
  3. Each commit should have a very explanatory message which resembles the change you are committing.
  4. Each commit must have issue number as reference
  5. Learn commit message good practices

Pull Request(PR)

  1. Before creating PR do self code review(CR). If you find any issues/improvements, postpone creating PR and fix the issues first.
  2. If the feature needs large changes, you can create PR in an early stage to review by peers.
  3. Inform team members to do CR by mentioning them in PR comment. You can also inform offline if CR has to be done urgently.
  4. If there are large numbers of commits and PR is created for the main branch(master/develop), squash merge all commits to create a single commit. Follow commit message conventions. Close the PR by adding appropriate comment and squash merge commit URL. Test(automated/manual) again thoroughly.
  5. Delete the working branch once it is merged to develop

Pre-Deployment

  1. Mark issue as ready to deploy when your working branch is merged to develop branch, tested(manual and automated) develop branch locally again and working all functionalities as expected.
  2. Identify all task which required to make the application work like environment variables, seed data, rake task, scheduler etc.

Post Deployment

  1. Remove ready to deploy status after deployment is successful.
  2. Mark issue as ready to test when deployment is complete and assign to QA(if available).
  3. Do through testing of the functionality you released in the last deployment.
  4. Send detail status to the client.
  5. Update documents like API, wiki etc about the released functionality.

Create Release

  1. After successfull relase, merge release branch in master
  2. Create a relase selecting master branch and details description in Github
@gs2589
Copy link

gs2589 commented Aug 17, 2018

  1. create new branches off develop. keep merging the branches via PR into develop so that other developers can have latest codebase
  2. create new branch off develop with name of release/{release_name} when you agree to release it on production
  3. PR/Merge release branch into master
  4. merge master back into develop

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment