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:
- 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 apidevelop
- 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, 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 right now or perhaps we backoff the amount Postman tests we add??. --Mark ) As As you add code to your repository, make sure you are adding unit/postman tests and, in the future, checking the Cobertura code coverage thresholds using the following commands (does Cobertura give coverage results for Postman tests?? -Mark):
- 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
Can Cobertura check coverage for but JUnit and Postman tests?
- mvn clean cobertura:cobertura
- IN THE FUTURE: Check Cobertura code coverage thresholds:
- mvn clean cobertura:check
- Run unit tests
- 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)