User Tools
Writing /app/www/public/data/meta/development/bitbucket_guidelines.meta failed
development:bitbucket_guidelines
Differences
This shows you the differences between two versions of the page.
| Both sides previous revisionPrevious revisionNext revision | Previous revision | ||
| development:bitbucket_guidelines [2019/04/29 12:59] – [Reviewers] edillon | development:bitbucket_guidelines [2023/01/31 12:16] (current) – [Reviewers] 10.91.129.55 | ||
|---|---|---|---|
| Line 1: | Line 1: | ||
| + | ====== Bitbucket/ | ||
| + | --- // | ||
| + | |||
| + | A presentation of this process as well as a guide can be found here : https:// | ||
| + | |||
| + | The initial review (credits to Anna!) - https:// | ||
| + | |||
| + | Note : It is the responsibility of the person who opened the PR to merge it, not the person who approves it. Though there are circumstances where the approver/ | ||
| + | |||
| + | ===== Branching and Commit Conventions ===== | ||
| + | Feature branches should include the name (IDMS-1235) of the ticket (or one of if many tickets) at the start of the branch name such as: | ||
| + | |||
| + | IDMS-1234-description | ||
| + | |||
| + | Every commit message should also contain the ticket, example commit message: | ||
| + | |||
| + | IDMS-1234 : Setting up a git demo | ||
| + | |||
| + | |||
| + | ===== The Process ===== | ||
| + | * Checkout the main/rel branch and pull the latest changes | ||
| + | * Checkout your branch | ||
| + | * Merge the base branch into your current branch - this will spot any merge conflicts (if any) and you should resolve locally via Intellij Merge features | ||
| + | * Push your branch | ||
| + | * Before creating a PR, ensure that you have a **stable build** on your branch. | ||
| + | * Log into Bitbucket in a browser and go to the project you have been working on, click pull requests and click open new pull request - (you can do this via the command line but it would be better to do everything through Bitbucket where possible) | ||
| + | * It should automatically populate if you just pushed your branch, if not you want to merge your branch into the main/rel branch | ||
| + | * **Ensure to check Close Branch. This will close the branch and delete its Jenkins build once merged.** | ||
| + | * Once pull request is open you will need to wait for someone to approve it - if it is important ask someone to review it if it is urgent or your notice it should should have been approved by now | ||
| + | * Once approved you can merge (ensure you squash your commits) your branch into the main/rel branch | ||
| + | * Ensure that you commit to the correct destination(s), | ||
| + | |||
| + | ===== PR Checklist ===== | ||
| + | //This is just a guideline, common sense should be used when reviewing PR's// | ||
| + | |||
| + | * Ensure code readability / commenting where necessary / javadoc. | ||
| + | * Good design / Security considerations. | ||
| + | * Inclusion of flyway scripts where necessary (e.g. new domains, updates to existing domains etc.) | ||
| + | * **DO NOT MODIFY AN EXISTING FLWAY SCRIPT!** | ||
| + | * Ensure integration / unit tests are present (depending on the complexity of the PR / Feature, more / less tests may be expected. This should be handled on a case by case basis.) | ||
| + | * Ensure any local files such as .idea etc are not committed by including them in the .gitignore. | ||
| + | * Check code formatting. | ||
| + | * Ensure conflicts are resolved. | ||
| + | * Ensure stable build is present on PR. | ||
| + | * Check the Sprint for the JIRA ticket(s) being merged - only the current sprint tickets should be merged to dev. | ||
| + | |||
| + | {{: | ||
| + | |||
| + | | ||
| + | {{: | ||
| + | | ||
| + | |||
Page Tools
