Page Comparison

The OpenMDM project is using an Agile Project Management methodology. Our work revolves around 3 week Sprints. The sprint artifacts are derived from our JIRA Story/Issue backlog. Our Sprints are managed using a set of standard meetings:

...

• During Sprint Planning, we will attempt to assign Stories/Issues to engineers
• After the Sprint Planning meeting, engineers (QA & developer) will task out their stories in JIRA
• When an engineer starts working on a Story/Issue, they should "Start Progress" in JIRA. Right now we are ignoring the "Begin Business Analysis" and "BA Review Complete", so you can skip through them.
• The Technology Center uses Git for version control. Git is a distributed version control system (DVCS) as opposed to a centralized version control system (CVCS). If you have not used a DVCS, (Git, Mercurial, Bazaar), please go through an online tutorial, as there are significant differences between DVCS & CVCS. Below are a couple of tutorials: 
  • http://blogs.atlassian.com/2012/02/version-control-centralized-dvcs/
  • https://www.atlassian.com/git/tutorials/
  • http://rogerdudler.github.io/git-guide/
• In Git, you should create a branch off of the "api" branch with a branch name matching the following format "feature/MDM-XXX" where MDM-XXX matches your JIRA Story/Issue
  • git checkout api
  • git pull
  • git branch feature/MDM-XXX
  • git checkout feature/MDM-XXX
• For the duration of your Story/Issue work, you can/should commit to your work often to your local repository. You can/should also push your work to BitBucket. Be aware, that when you push your branch to BitBucket, a Jenkins build will be triggered (Do we really wan to automatically trigger a test? Doesn't QA want to control that? --Mark), the unit tests will be run and, in the future, Cobertura code coverage thresholds will be checked. We may want to limit the length of this test to a short (10 mins or less) sanity test and then add a longer nightly test?
  • Use "git add" to "stage" the files you have changed or want to add to the repository 
  • The following command can be used to commit to your local repository:
    • git commit \-m "MDM-XXX - a description of the change"
• (I like this but lets talk about unit testing – we have been relying on Postman testing and with an API I'm not convinced we need it. --Mark ) As you add code to your repository, make sure you are adding unit tests and, in the future, checking the Cobertura code coverage thresholds using the following commands:
  • Run unit tests
    • mvn clean package
  • IN THE FUTURE: Generate Cobertura code coverage web reports:
    • mvn clean cobertura:cobertura

      • In module being built, run the following command (on a mac):

        • open target/site/cobertura/index.html

  • IN THE FUTURE: Check Cobertura code coverage thresholds:
    • mvn clean cobertura:check
• Also, as you push your branch to BitBucket, make sure the Jenkins builds are passing. If the Jenkins builds are not passing, your Story/Issue is not complete.
• As you are working on your feature branch, its a good idea to merge "develop" into your branch occasionally.
  • There are multiple ways of doing this. One way is to have your branch checked out locally and run the following command:
  • git merge origin/develop
• Push your code from your local repository into the Bitbucket repository (origin)
  • git push origin feature/MDM-XXX
• Before you do your "Pull Request" merge develop into your feature branch.
• Once your coding is complete and the Jenkins builds are passing, you can do a Bitbucket "Pull Request".
  • When you do a "Pull Request", pick some reviewers.
  • If the reviewers make comment or change requests, make those changes on your feature branch and update the "Pull Request" in Bitbucket
  • Mark your JIRA Story/Bug/Task as "Ready for Code Review"
• Once the review is complete and all the changes have been made as a result of the review and the reviewers have "Approved" the "Pull Request" in Bitbucket, you, the developer, can perform the "Merge" into the develop branch.
  • Mark your JIRA Story/Bug/Task as "Passed Code Review"
• Merging into the develop branch will trigger a deployment to the QA environment
• Go out to the QA environment and do a quick sanity test on your Story/Issue.
• Mark your Story/Issue as "Ready for QA". Marking a story as "Ready for QA" means that it has been deployed to the QA environment and is ready for a QA engineer to do manual and automated testing against that QA deployment.
• Make sure to update any documentation (READMEs, Confluence pages) with any new behavior/set-up required resulting from your Story/Issue
• Once the QA engineer has completed their work on a story/bug/task, they will mark the story as "Ready to Deploy"
• "Ready to Deploy" means that this story is ready to be deployed to the Production environment. (Currently, we do not have a production environment)