EDP Project Rules. Working Process⚓︎

This page contains the details on the project rules and working process for EDP team and contributors. Explore the main points about working with Gerrit, following the main commit flow, as well as the details about commit types and message below.

Project Rules⚓︎

Before starting the development, please check the project rules:

1. It is highly recommended to become familiar with the Gerrit flow. For details, please refer to the Gerrit official documentation and pay attention to the main points:

   a. Voting in Gerrit.

   b. Resolution of Merge Conflict.

   c. Comments resolution.

   d. One Jira task should have one Merge Request (MR). If there are many changes within one MR, add the next patch set to the open MR by selecting the Amend commit check box.

2. Only the Assignee is responsible for the MR merge and Jira task status.

3. Every MR should be merged in a timely manner.

4. Log time to Jira ticket.

Working Process⚓︎

With EDP, the main workflow is based on the getting a Jira task and creating a Merge Request according to the rules described below.

Commit Flow

1. Get a task in the Jira/GitHub dashboard. Please be aware of the following points:

   JiraGitHub

   a. Every task has a reporter who can provide more details in case something is not clear.

   b. The responsible person for the task and code implementation is the assignee who tracks the following:

   • Actual Jira task status.

   • Time logging.

   • Add comments, attach necessary files.

   • In comments, add link that refers to the merged MR (optional, if not related to many repositories).

   • Code review and the final merge.

   • MS Teams chats - ping other colleagues, answer questions, etc.

   • Verification by a QA specialist.

   • Bug fixing.

   c. Pay attention to the task Status that differs in different entities, the workflow will help to see the whole task processing:

   

   d. There are several entities that are used on the EDP project: Story, Improvement, Task, Bug.

   a. Every task has a reporter who can provide more details in case something is not clear.

   b. The responsible person for the task and code implementation is the assignee who tracks the following:

   • Actual GitHub task status.

   • Add comments, attach necessary files.

   • In comments, add link that refers to the merged MR (optional, if not related to many repositories).

   • Code review and the final merge.

   • MS Teams chats - ping other colleagues, answer questions, etc.

   • Verification by a QA specialist.

   • Bug fixing.

   c. If the task is created on your own, make sure it is populated completely. See an example below:

   

2. Implement feature, improvement, fix and check the results on your own. If it is impossible to check the results of your work before the merge, verify all later.

3. Create a Merge Request, for details, please refer to the Code Review Process.

4. When committing, use the pattern: commit type: Commit message (#GitHub ticket number).

   a. commit type:

   feat: (new feature for the user, not a new feature for build script)

   fix: (bug fix for the user, not a fix to a build script)

   docs: (changes to the documentation)

   style: (formatting, missing semicolons, etc; no production code change)

   refactor: (refactoring production code, eg. renaming a variable)

   test: (adding missing tests, refactoring tests; no production code change)

   chore: (updating grunt tasks etc; no production code change)

   !: (added to other commit types to mark breaking changes) For example:

   feat!: Add ingress links column into Applications table on stage page (#77)
   
   BREAKING CHANGE: Ingress links column has been added into the Applications table on the stage details page
   

   b. Commit message:

   • brief, for example:

     fix: Remove secretKey duplication from registry secrets (#63)

     or

   • descriptive, for example:

     feat: Provide the ability to configure hadolint check (#88)
     
     *Add configuration files .hadolint.yaml and .hadolint.yml to stash
     

     Note

     It is mandatory to start a commit message from a capital letter.

   c. GitHub tickets are typically identified using a number preceded by the # sign and enclosed in parentheses.

Related Articles⚓︎

• Conventional Commits
• Karma