Projects

https://support.yamnet.com/bitbucket/projects/CDP


Pattern

This is a high level description, if it is not clear ask! Or discuss what is missing to improve documentation

  1. Start development with a release/* branch from master.
  2. Create feature/* branch from release/* branch using JIRA "create branch"
  3. Merge feature/* into release/*.
  4. When done merge release/* into master.
  5. Even if you have just one feature it does not matter, follow the same pattern.
  6. Any bug found before production (master) is a branch bugfix/* on the release/* branch.
  7. Any bug found on production follows the same pattern. Create release/* from master, create hotfix/* from release/*. PR hotfix/* → release/*. PR release/* → master

NOTE: commits in feature/branch should be squashed to a single commit before PR into release is created. Adjust commit message to reflect only the changes. History will be lost for sure, but for readability this is much better. 

Squash

On local machine you have to figure out the number of commits on your branch. Most IDE can visualize a graph with all the commits on the branch, so count. From the command line:

git rebase -i HEAD~<number of commits>

This is interactive option. For each commit you must replace pick with squash and close/save when done. This opens the commit messages, Commit messages that does not make sense or not following the commit message standard (see below) can be adjusted. Remove any intermediate messages that does not make any sense at all, like the so often seen "Typo". Save/close the file. If everything went well ones can push the feature branch to origin. Probably have to --force the push.

Commit message

Always add the ticket identifier to the commit message:

B2C-9658:: Describe what changed in this commit; Describe another change in this commit related to B2C-9658.


CICD (draft)

NOTE: The setup is open for discussion at any time!

branch - feature/*:

  • Target : test

branch - release/*:

  • Target : accept

branch - master:

  • Target : production

Pull Request (PR) release/* into master:

  • This can replace branch - master pipeline. If true, the branch - master pipeline does not exist. The code in master is only for administration which reflects what is actually/expected in production.

Pull Request (PR) feature/* into release/*:

  • This can replace branch - release pipeline. If true, the branch - release pipeline does not exist. The code in release/* (need some attention on naming) is only for administration which reflects what is actually/expected in acceptance.

Tags:

  • There is no pipeline on tag creation. If there is a pattern to do so, open a discussion.


Repository Settings

TODO: Not clear if there is a standard in other projects, get in touch with development team

With images

Security