...

Start here: New Developer Workflow

Anchor
devworkflows devworkflows

Overview

• Git Workflows: Forking workflow with feature branches
  1. Fork repo (if applicable)
     • Press "Fork" in GitHub UI
  2. Clone repo to make changes locally (if applicable)
     
     • git clone https://github.com/USERNAME/ndslabs.git
     • git remote add upstream https://github.com/nds-org/ndslabs.git
  3. Ensure correct branch and sync with upstream before making additional changes
     • git checkout master
     • git pull upstream master
  4. Create a branch named after the Story (for example 

     Jira
     server JIRA serverId b14d4ad9-eb00-3a94-88ac-a843fb6fa1ca key NDS-174

     )
     • git checkout -b NDS-174
  5. Stage any modified files for commit
     • git add path/to/modified/file.ext
  6. Commit any modifications to your local branch with a comment
     • git commit -m "A comment about this commit"
  7. Push any local commits back up to your remote branch (your forked repo)
     • git push origin NDS-174
  8. When you are satisfied with your changes, create a Pull Request
     • Press "Pull Request" in GitHub UI
     • Scroll down and click on the "Files Changed" tab to briefly review your own Pull Request
       • Ensure that all changes made on this branch were intentional
     • Name your Pull Request after the Story / branch (i.e. "NDS-174: User can access console of running service via CLI") 
     • Enter a short description of any modifications, additions, or removals from the codebase
       • If applicable, include a Test Case that the reviewer should run before merging the Pull Request
     • Click "Create Pull Request"
• Docker Workflows: Upload any necessary test images to Docker Hub
  1. Build test image
     • docker build -t ndslabs/apiserver:dev .
  2. Tag test image with Story id (i.e. NDS-174)
     • docker tag ndslabs/apiserver:dev ndslabs/apiserver:NDS-174
  3. Push test image to Docker Hub
     
     • docker push ndslabs/apiserver:NDS-174
• Kubernetes Workflows: Sometimes used in testing new services or the API server

JIRA Workflows

To handle issue and project tracking we use JIRA, which currently offers several different Issue Types when creating new tickets.

The expected usage of each Issue Type is outlined briefly in the workflows below:

...

When a Requirements ticket is in the Active Sprint:

1. The ticket is marked IN PROGRESSand assigned PROGRESS and assigned to a developer, who conducts the meeting
2. A meeting is created in Outlook to contact interested parties (i.e. NDS Labs Dev team, Nebula team, other NDS-affiliated software teams, etc.)
   1. The requirements are discussed with the development team and any interested parties
   2. Any information resulting from the discussion is filed into a Confluence wiki page
   3. The information from the Confluence page generates use cases
   4. If applicable, a new Epic is created to encompass the use cases presented
3. The use cases are filed as Story tickets and associated to an Epic
4. The ticket is marked IN REVIEW and assigned to another team member for review
   1. The reviewer may make any changes or comments that they desire and discuss with the team
5. The ticket is marked RESOLVED or CLOSED
6. The resulting Epic / Story tickets are then discussed at the next Sprint Planning meeting

...

1. The ticket is marked IN PROGRESS and assigned to a developer (referred to hereafter as "the developer")
2. The developer does the work necessary to enable the use case described in the ticket
   1. Follow the the general development workflows defined belowabove
3. Comment on the Story with links to any deliverables that should be reviewed / tested
4. The ticket is marked IN REVIEW and assigned to a tester (referred to hereafter as "the tester")
5. The tester reviews the deliverables of the Story:
   1. Review any related Pull Requests
   2. Review any Test Cases / Documentation provided
   3. Review any new tickets resulting from the work done
   4. Pull and run any new Docker images against the Test Cases provided
6. The tester selects Review Accepted and the ticket is marked as RESOLVED
7. The tester merges any outstanding Pull Requests related to this ticket
8. The developer switches back to their master branch and syncs with the new changes
9. If applicable, the developer builds and pushes a new "latest" Docker image for the API / UI incorporating the new changes
10. The developer selects CLOSE TICKET and the ticket is marked as CLOSED

...

1. projects (via Account Creation Workflow)
2. service specs (via Pull Requests made to ndslabs-specs)

...

1. )

• Press "Fork" in GitHub UI

...

• git clone https://github.com/USERNAME/ndslabs.git
• gitt remote add upstream https://github.com/nds-org/ndslabs.git

...

• git checkout master
• git pull upstream master

...

...

• git checkout -b NDS-174

...

• git add path/to/modified/file.ext

...

• git commit -m "A comment about this commit"

...

• git push origin NDS-174

...

• Press "Pull Request" in GitHub UI
• Scroll down and click on the "Files Changed" tab to briefly review your own Pull Request
  • Ensure that all changes made on this branch were intentional
• Name your Pull Request after the Story / branch (i.e. "NDS-174: User can access console of running service via CLI") 
• Enter a short description of any modifications, additions, or removals from the codebase
  • If applicable, include a Test Case that the reviewer should run before merging the Pull Request
• Click "Create Pull Request"

...

1. Build test image
   • docker build -t ndslabs/apiserver:dev .
2. Tag test image with Story id (i.e. NDS-174)
   • docker tag ndslabs/apiserver:dev ndslabs/apiserver:NDS-174
3. Push test image to Docker Hub
   
   • docker push ndslabs/apiserver:NDS-174

...