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.
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.
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.
Release Branches are used in projects that do not (yet) use Continuous Delivery and are put together to be reviewed by our Product Owner or other teams. Release Branches are pulled off master and are deployed to a staging environment for review. After review is completed it is then merged into the production branch. If Continuous Delivery is employed, master is the production branch.
All development work centers around GitLab, where we have enterprise accounts at gitlab.com for all members of the development teams.
Issue life cycle
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.
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 time frame of the current sprint.
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.
People assign themselves to issues, so when in doubt, do not assign a ticket to someone else.
If the issue is considered difficult by the person who wants to do it, 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. Complicated issues are also good candidates for pair programming.
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.
Rebase frequently to incorporate changes from master brach and make sure it is mergeable with fast-forward before submitting a merge request.
Committing codeFor committing code we recommend the following format for all our projects, where
#XXXreferences the issue number in Gitlab for the project.
#XXX Imperative summary of issue under 80 characters * More information about commit. * More information about commit.
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 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.