DS Workflow Changes

Process

Text

Workflow

Tools

Process

Services

Workflow

JIRA

Github

Services

Release

wow

1. JIRA and Github

2. Feature work / bug fixes

3. Reviewing

4. Testing

5. Releasing

 

Overview

JIRA

  • In development
  • Code Review
  • Awaiting IO Deployment
  • Feature Review
  • Awaiting Stage Deployment
  • In QA / UAT
  • To Deploy

Github

  • Create feature or hot / bugfix branch
  • Code review
  • Feature review
  • Releasing

1. Github and JIRA

2a. Feature work

  • Know the milestone for your feature 

  • Create feature branch from develop:

 

 

 

 

 

  • Open PR and Label as Ready for Code Review when complete (or ask for help)

develop

feature/HDS-136_fix_page_performance

2b. Bugfix work

  • Bugfixes are branched from master:

 

 

 

 

 

  • Open PR back to MASTER and Label as Ready for Code Review when complete (or ask for help)

  • You will likely also want to open a PR against DEVELOP but check

master

bugfix/HDS-91_Corrected_menu_overflow_issue

3. Reviewing

 

  • Code review is looking at more than just syntax and formatting

    • Any obvious problems caused by the code

    • Examine how the problem was solved

      • Could it be done in a more performant / generic way

    • Syntax / formatting issues

  • If it passes code review, change label to ready for feature review and move to awaiting .io deployment

 

  • Deploy the feature branch to the .io environment

  • If it passes feature review it can be merged & / or marked as Ready for Release.

 

 

 

4. Testing

  • Features are tested individually when marked as Ready for Feature Review on the .io environment

 

  • When a collection of featues are ready, we merge develop into master

 

  • The code in master becomes a 'release candidate' (and should be tagged as such: e.g. 11.30.1-rc1)

 

  • This release candidate is release ready and can be fully tested on stage as such.

5. Releasing

  • If the release candidate is QAed and has no problems, we can tag the release (e.g. 11.30.1.0 and build that on production).

 

  • If there are any issues we adhere to the bugfix process, (branch from master, fix it, open PR, test and merge branch in).

 

  • Tag the release from master (.e.g. 11.30.1.0)
  • Update changelog.md with the ticket numbers and a brief overview of what has happened.
  • Deploy. Inform editorial (push them to view the changelog)

Any Questions?

Made with Slides.com