Version Control

We always use source code control. It's like a time machine. We can work in parallel universes of our source code, experimenting without fear of losing work, rolling back if something goes wrong.

Git

We exclusively utilize Git for our versioning of code, documentation and plain text data. We strongly encourage learning the tool well, as it is powerful and allows a lot of flexibility and control. For this reason we recommend not utilizing graphical git clients, but encourage learning the options it offers on the command line.

Git LFS

For storage of binary or large data, we recommend using our internal storage box, or Git LFS.

How we use Git Branches

The Master branch of a project represents a deployable and deployed (or about to be deployed) state of a project. It is not used as a development branch unless the project is as-of-yet unreleased. The CI Pipeline (tests, linters) should never fail on a Master branch.

The Staging branch of a project represents a deployable and deployed (or about to be deployed) state of a project for the staging environment. It mirrors master, except that unreleased feature branches are merged into it to get tested and reviewed in the staging environment.

Feature Branches are used to develop singular issues and test them independently. They are always based off a version of the master branch. Before merging them back, master is merged into them or they are rebased off the current master to avoid any issues.

Gitlab

All development work centers around Gitlab, where we have enterprise accounts at gitlab.com for all members of the technology teams.

Issue life cycle

Backlog

Our backlog of open issues is tracked through the Gitlab issue system. We regularly add new issues through feedback from other teams, customers, or internally. Old issues are cleared out about once a month.

Sprint Backlog

Our sprint backlog is decided upon once per sprint as part of our spring meeting. It is modeled as a Gitlab milestone and contains all issues that are designated to be done within the timeframe of the current sprint.

Assigned Issues

When we start working on an issue, we assign it to ourselves in Gitlab to make clear that somebody is already working on it and nobody else will do the same work.

If the issue is weighted with more than 3 issue weight, we recommend that the person working on the issue does a kickoff with someone else from the team in order to make sure that a proper strategy for tackling the problem is chosen.

Creating a feature branch

Feature branches are branches in git that are specifically created to track the development of an issue (feature or problem alike). Feature branches can be created using the GitLab UI and checked out as a remote branch from origin afterwards.

Coding, Committing & Pushing

All code should be committed properly on the branch. Make sure not to commit code that is not needed, and base branches off master, and not another feature branch. Push all code at the end of the work day or earlier if you are taking extended breaks from your work. This is not only for security, as local code is not backed up and only accessible to one developer, but also so that others can see what you are working on, and potentially even provide early feedback or reviews.

Merge Requests

When you are done with the issue, create a merge request and assign it to someone for review. When the issue has been approved, merge it onto master and begin deployment steps.

For more details on Code Reviews, check the appropriate section within this playbook.

Deployment

Deployment strategies depend on the project you are on. Usually they are either partially or fully automated. Look at the Readme of the project and consult with a more senior person on your team for your first deployment.