Housekeeping

The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT" and "MAY" in this document are to be interpreted as described in RFC 2119.

Principles

  • If it hasn't been pushed, it doesn't exist.
  • If it hasn't been tested, it doesn't work.
  • If it's not on JIRA, you haven't done anything.

Standup meetings

On Mondays, Wednesdays and Fridays, write a quick summary of your progress in #dev-standups answering:

  • What have you done since previous summary?
  • What do you plan to do until next summary?
  • Are you blocked by anything?

Initial Setup

You MUST define the following git settings (make sure to change to your own name and email):

git config --local pull.rebase true
git config --local user.name "John Doe" # your full name
git config --local user.email johndoe@example.com # your @igem.org email

You MAY replace --local with --global if you want these settings to be set for all repositories in your computer. Otherwise, you MUST define them for every new repository.

Branches

Deployments

  • working (local) branches MAY be deployed to development environment, using unreal data only
  • preprod branch automatically deployed to preprod environment, using a hot version of the DB and services
  • production branch automatically deployed to production environment

working branch → development (PRs, reviews happen here) → preprod (shouldn't move back unless bug) → production

Working Branches

Syntax: [type]/[issue-no]-[title]

Types

  • feat: feature branches
  • bug: bugfixes and corrections
  • ci: continous integration and infrastructure branches
  • misc: other branches which don't fit in to the categories above

Issue number

  • 3-digit GitLab/Jira issue number, for easier tracing or searching, padded with zeroes for better sorting (001, 123, etc.).
  • Not required if it's misc or a quick fix.

Title

  • A concise name for the feature/fix/other
  • Use hyphens for separating words

Examples

feat/004-certificates, bug/042-log4j-exploit, misc/change-copyright-to-2022

Merge requests

Revision

  • Create a merge request from your working branch to preprod as soon as your branch is ready to start being reviewed
  • Write a notification (with link) to your MR on #dev-merge-requests slack channel with the size of it (e.g., S - small merge request, M - medium, L - large)
  • Reviewer MUST approve MR

Merging

  • Merge Requests to preprod SHOULD be squashed
  • To be accepted, all merge requests MUST be reviewed by a maintainer.
  • Merge Requests to production SHOULD NOT be squashed

GitLab autocloses issues if merge request has a specific pattern. Let's use this.

GitLab does not autoclose Jira issues, only references them

Examples: Jira issue MY-3, write in the MR: Closes #MY-3.

Tests

For consistency, let's use the Arrange-Act-Assert pattern.

Commit message

Use imperative mood - spoken or written as if giving a command or instruction (Also can be read as “this commit should/will [commit message here]”). The commit body MAY be added if necessary. Commits SHOULD reference a subtask from JIRA at least. Optionally, commits may reference a story from JIRA.

Inspired by https://cbea.ms/git-commit/

Examples

  • Refactor subsystem X for readability
  • Update getting started documentation
  • Remove deprecated methods
  • Release version 1.0.0

results matching ""

    No results matching ""