Skip to end of metadata
Go to start of metadata
Git Branching Model/Workflow
- Master branch is the primary branch and all feature branches should come out of it.
- feature branch with jira number
- Branch Names:: AMP-XYZ_simple_description (AMP-12_adds_collects)
- Features should be merged into master
- before commits, rebasing to originating branch to make sure all conflicts are resolved
- commit message: brief description, of the commit. make as many commits you want.
- master is always protected.
- in future we can add one or more branch/environments
Pull Request Requirements
- Code is written
- Wiki Documentation is created (if needed)
- Code is documented, (JavaDoc style comments)
- All Objects created in PR are tested
- All modified Objects have updated tests
- All tests are passing
- If new properties are added to application.properties that need to be customized, make a note in the PR comment, and notify other devs to update their local properties ; also update CI (Bamboo) and Test (Potassium) properties or environment variables as needed.
- PRs would be squashed by default unless mentioned by the author in comments to merge it.
- Applications shall be deployed in success after merge before story is closed.
- Code shall follow best practice standards.
- Code is written in a modular way following the conventional structure and naming standards.
- Services shall have API comments following javadoc format. Add abundant comments as needed to make code more readable.
- Log at info/warning/error level for all important processes, exceptions, error messages.
- Highly important: never commit any security related info into repository. We shall define those as environment variables and put fake default values in application.properties, so the real values can be defined in each environment.
- Circle-CI for running builds and automated deployments
- Codacy for automated code reviews
Unit Tests Framework
- JUnit for unit testing
- TestNG for functional testing
- Server: Tomcat 8
- War file will be deployed to Tomcat