Workflow Overview

Introduction

The workflow we use for FieldWorks development makes use of three tightly coupled tools: Git (DVCS), Jenkins (Continuous integration server), and Gerrit (Code review server). All three tools are installed on a server.

The main git repo (also called the remote repo) has two major branches: The master branch has the latest released version, and development for the next version happens on the develop branch. When preparing for a new release we create a release branch (e.g. release/8.0) that gets labeled and merged into the master branch when the software is released. The developers create additional feature branches on their local machines which usually don’t get pushed to the remote repo.

Typical workflow

The typical workflow for a developer looks like this:

1. Developer clones the remote git repo (one-time setup)
2. When starting a new task the developer pulls the latest changes from the remote git repository
3. He creates a new feature branch based on the tip of the develop branch locally on his machine (e.g. feature/FWR-1234 -- In Git GUI, choose Tools > 0_Feature > 0_Start, and enter the request number from JIRA; this will also set some things behind the scenes)
4. He makes changes to the code
5. He commits the changes to his local git repository
6. Repeat step 4 and 5 until the task is done
7. Optionally he can squash multiple (local) commits into one to clean up the commit history
8. He submits the changes to Gerrit for code review. Each commit appears as one code review task in Gerrit, so when making multiple commits for the same feature, it is best to choose the Amend Last Commit radio button in Git GUI
9. As soon as a commit is pushed to Gerrit for review, Jenkins pulls the changes and triggers a build which will run all the tests. If Jenkins can’t build with the changes or tests fail, the developer gets informed and continues with step 4
10. Someone else reviews the code changes on Gerrit. If the changes need to be improved, the developer gets informed and continues with step 4
11. Gerrit merges the changes to the develop branch
12. Jenkins triggers a continuous integration build of the develop branch
13. Developer pulls develop branch from Gerrit and deletes his local feature branch

The workflow when working on a release branch is basically the same — except your local branch is forked from master instead of from develop.

The big advantage of this workflow is that the developer doesn’t have to run all the tests prior to pushing to the remote repo. Gerrit and Jenkins will do a build and run all the tests with these changes. This saves quite a bit of time for the developer and enhances the code quality since it reduces the occasions where broken code is checked in to the remote repo.