Developer workflow - SoudagarAijaz/jetblueairways-SSIS GitHub Wiki

Workflow

There will be two primary branches - master and staging. Master represents production, and staging represents staging.

Each branch will contain a folder for each application/project, wherein the relevant files will be contained.

If Sql scripts need to be included in the project, we can create a folder with name SQLScripts and add the scripts as test1.sql.

The workflow for deploying changes is:

  1. Developer creates a new branch off of the master branch.
  2. Developer adds/updates/deletes files within the corresponding project folder on the new branch. If no existing project folder exists, create one.
  3. Developer commits and pushes those changes into the branch.
  4. Developer opens a pull request to merge those changes into the staging branch, filling out the entire pull request template. The ServiceDesk change request ticket should contain a link to this pull request.
  5. If the user creating the pull request is not the developer, they should request a review by the developer in order to obtain signoff.
  6. The DBA team is automatically assigned as a reviewer:
    • If review results in an approved status, it is applied to the staging environment during the implementation window and confirmation of release should be added via comment on the pull request. The feature branch is deleted.
    • If not approved, the pull request is rejected and changes are requested. The developer goes back to step 2 once code is fixed.
  7. The developer provides any business-side validation required as a comment on the pull request - not via email.
  8. When ready for production release, the developer creates another branch via the git command line to capture the desired changes from the appropriate project folder:
git checkout master
git checkout -b MyProdReleaseBranch
git checkout staging -- project1/*
  1. The developer opens a pull request into master with this new branch.
  2. The review process then repeats and the change is deployed to production during the implementation window.

Branching

  • When creating a branch, give it a short but accurate name that describes the changes it contains. Try to avoid using names like ods-master1, ods-prod, and ods-staging-update that are unclear and may be confused with the base master/staging branches.

Branch Retention

After a branch has been merged, it should always be deleted. There is no benefit to keeping around old branches and they can quickly grow to an unmanageable number. Should you need to recover a deleted branch, it is always possible.

Help

If you're new to GitHub, check out this repository's wiki which has links to resources on using GitHub. GitHub Desktop is an easy to use UI for those new to GitHub.