Like many development shops, we’re standardising on GitLab in 2017 as the distributed version control tool of choice.
It can take a little while to refine and polish a workflow that is productive and auditable across multiple developers and projects.
Here’s what we’ve got so far.
- Create a new issue in gitlab, detailing the work to be carried out. Include checklists, images, failing tests, all the information needed to carry out the work.
- Assign the issue to a developer, so they know it’s on the radar. The issue will be discussed in the issue thread until mockups, specs, other details are ready.
- Developer Creates a new branch for the issue, and checks it out in their local machine to work on. Developer estimates time required with a /estimate comment on gitlab.
- Hit the ‘Toggl button’ in gitlab to start time tracking for this issue. (* You’ll need to install the toggl chrome extension for this)
- Developer writes code and tests, verifies all tests are passing, and git-pushes work up to the remote branch.
- Developer adds a /spend comment on gitlab for time taken.
- When satisfied, developer creates a merge request on their branch.
- Project manager reviews code and pulls into master/develop branch as available, or adds comments to the commit for the developer to correct.
- (Repeat steps 4-8 until commits are approved)
GitLab has had a rocky start to 2017, with a MAJOR outage last week (February, 2017) with data loss due to lost backups. Since it’s a Distributed Version Control provider, GitLab is only really hosting a copy of data we hold internally on development machines and internal backups anyway.
It’s easy to see the professionalism of your partners in the face of an event such as this — GitLab kept a live blog running, explaining the outage in detail with key events and constantly updated information for data recovery. It’s a scary outage for sure, but their transparency means we can keep an eye on how they internally deal with the situation and implement strategies to stop it in the future.
