Deployment Procedure (GitHub Projects)

Deployment Procedure (GitHub Projects)

This document outlines a recommended procedure to deploy projects into Dev, Staging and Live environments when using Git.

The idea is to control deployments and ensure code is deployed correctly and efficiently.

This recommendation starts from the project set up through to committing code and finally when code is pushed live.

Project Setup

1. Create the following branches:

• DEV: The development branch.
• STAGING: This branch should be used to push to the staging environment. Should only be merged with the ‘DEV’ branch.
• MASTER: This will be the live branch. Should only be merged with the ‘STAGING’ branch.

2. Create the following folder structure for your project. Create the following folders in the root of the project:

• src: This is for your code.
• release notes: This is to keep track of releases/deployments (will be explained below).
• deployment details: This will contain detailed information for each deployment/phase.

Deployment Details

For each phase/deployment create a text file which outlines the changes made to the project. Similar to a changelog.

Follow these simple rules:

• naming the file: Name the file ‘phase’ followed by current phase number and then the date, such as ‘phase1_20130708’.  Remember to keep this in sync with the ‘release notes’

Release Notes

This folder will contain text files with all the file paths to any new or amended files.

For example:

\lib\com\fahimchowdhury\component\UIElement.js \lib\com\fahimchowdhury\display\DisplayObject.js

Follow these simple rules:

• naming the file: Name the file ‘release_phase’ followed by current phase number and then the date, such as ‘release_phase1_20130708’.  Remember to keep this in sync with the ‘deployment details’

Deployment Procedure

1. Create a deployment details text file outlining what the next release contains and follow the correct naming conventions.
2. Create a release note and follow the correct naming conventions.
3. When committing code, copy all the file paths and place it into your release note.
4. When pushing to staging add the following text in the commit message before you write anything else. Replace N with your phase number.
   
   ‘STAGING RELEASE PHASE N’
   
   
5. Tag the Master branch. Use the following naming conventions (replace N with your phase number and then add the date and time): 
   
   Phase_N_YYYYMMDD_HHMM
   
   
6. When pushing to the live site add the following text in the commit message before you write anything else. Replace N with your phase number.
   
   ‘RELEASE PHASE N’
   
   
   
   
   

   Alternative Approach with Tags

   
   
   

   The is another effect way of deploying with ‘tags’. You only need two branches:

   
   
   

   • DEV: The development branch.
   • MASTER: This will be the staging branch. Should only be merged with the ‘DEV’  branch.

   
   
   

   Deployment Procedure

   
   
   

   1. Create a deployment details text file outlining what the next release contains and follow the correct naming conventions.
      
      
   2. Create a release note and follow the correct naming conventions.
      
      
   3. When committing code, copy all the file paths and place it into your release note.
      
      
   4. When pushing to staging add the following text in the commit message before you write anything else. Replace N with your phase number.
      
      ‘STAGING RELEASE PHASE N’
      
      
   5. When pushing to the live site Tag the Master branch. Use the following naming conventions (replace N with your phase number and then add the date and time):
      
      Release_Phase_N_YYYYMMDD_HHMM
      
      
   6. Deploy the tagged code to the live site, pull the code and upload the relevant changes. follow the ‘release notes’.