Synchronizing Tasks Inside the Company
Our branching model for iOS
The larger the team, the more likely it is for problems to occur as multiple people are working on the same codebase. To guarantee an obstruction-free and collaborative workflow, just knowing your git commands doesn’t cut it. Therefore, it is necessary to define a branching model which accommodates internal processes and limits complications that emerge from a group of people working synchronously.
At Wolox, our goal is to make the process of managing our branches easier for the developers while also saving time when sending builds for the Quality Assurance (QA) department to test.
The result? By implementing this model the quality of our products improved as QA could test with a more integral approach.
An Epic (user) Story
Our branching model at Wolox for the iOS department is based on the concept of Epics, or User Stories. Several different definitions of such concepts exist, yet at Wolox, we define them as the group of tasks that make a complete feature adding value to the end user. An epic only makes sense when all the tasks that it contains are finished.
Quality Assurance (QA)
One of the main advantages of working with epics is the simplification of the QA process for both devs and testers. In this model, we send the QA team the epic once it’s done. By doing this, the dev saves time from having to build a .ipa for every task and the QA team can test the full feature as well as the interaction between its components. This facilitates the process on both ends and makes the testers’ job more effective, leading to a enhanced overall quality of the product.
Our Branches
Master
In our master branch, we find our latest release. This branch should always contain working and deliverable code.
Dev
The dev branch branches out from the master. Here we can find epics that have already been approved by QA. At Wolox we use Scrum, so after each sprint ends we merge this branch to master, after checking that the different epics that are merged here work with each other. Depending on your methodology or the specifics of your project, you can also merge to master once you show the progress to your client, either an internal or external one. Keep in mind that master must always contain code that is working correctly, so be mindful when you merge.
Epic-{epic name}
Every epic branch contains the commits that have already been code reviewed and whose pull requests’ have been approved. Once all the tasks from the epic pass our Code Review process, a .ipa is built and sent to QA. Remember to rebase from dev first!
*A good tip to avoid bad merges is to have protected branches.
{epic name}-{feature name}
Every feature branches out of the epic it corresponds to. Here the developer makes the necessary commits to implement the task or feature. Once it’s finished, the dev opens a new Pull Request for Code Review, having the epic branch as destination branch.
Let’s put this to play…
Imagine a project which already has a couple of releases, and where the master and dev are up to date. In our next sprint planning, we decide to develop three new functionalities:
- View A redesign
- A new view (View B)
- Implementing push notifications
Therefore, we’ll create 3 new branches from dev:
- epic-screen-A-redesign
- epic-screen-B
- epic-push-notifications
We must chose an owner for each epic, who will then be responsible for creating the new branch in the repository so that every member of the team has the same one. This person will also create the Test Plan when necessary and build and send the .ipa to the QA testers once the epic is finished. Although the epic has an owner, this does not exclude other devs from working on the epic in the feature-branches.
Likewise, in the sprint planning, we can define the tasks for each epic or leave it up to each dev or group of devs. These would be the four features that branch out of our epic-screen-B branch:
- screen-B- design where we implement the view and front-end
- screen-B- backend where we develop the back-end and connection to external services. At Wolox, backend does not mean web backend services; it is where we manage our logic and non-UI code.
- screen-B- flow where we connect this screen with the app’s existing flow.
- screen-B- table where we develop the table view that the screen contains, as it is deemed too complex to include in either of the front-end or the back-end branches.
Each team can decide whether to let one or multiple devs work on each epic.
Once screen-B-table is developed, a new Pull Request is opened to epic-screen-B. Here the Code Reviewer makes comments and the dev makes the corrections. Once this process is finished, after the necessary comes and goes, the reviewer approves the Pull Request and the branch is merged to epic-screen-B, allowing this feature to be available to all devs working on this epic, and speeding up development of the app.
Once all four feature branches are merged, we build a .ipa and send epic-screen-B to QA,
After rebasing this branch to dev. Here the QA engineers who work on this epic mark the errors they find. Once these are sorted out (adding commits in the epic branch), and once the changes are reviewed in a new Pull Request, a new build is submitted to QA. This process is repeated until QA gives the thumbs up. Only then is epic-screen-B merged to dev.
At the end of the sprint, with the three new epics merged to dev, we give the client a demo of what has been achieved. Once the client approves our work, we merge dev to master.
When we make a release, such as a new App Store or a Test Flight submission, we create a tag in the master branch, containing the release version. This will make a rollback easier in the future if needed, as these tags indicate a working, deliverable version of the app.
What about bugs?
We found over time that there are some cases where an issue does not belong to an epic. This is common with bug fixes and tech issues. At Wolox we usually branch out straight from dev for these kinds of tasks, avoiding using an epic for a single issue. We still respect our methodology, so before merging, we have our code reviewed via a Pull Request and submit a build for QA to review.
Final thoughts
I hope this has given you an overview of how we work here at Wolox. We have developed this branching model after several changes, discussion, and strategizing sessions, and for now, it suits our needs and allows us to work efficiently and collaboratively.
We found that our speed increased dramatically, that the overall quality of the product improved and that our devs and testers were more satisfied with this model. Our planning meetings are more effective and our processes are more efficient.
However, this is by no means is a strict model. The ideas we use can and should be adapted to suit your needs and processes. I hope you can take some of these ideas as you develop your Branching Model, and look forward to reading your opinions and ideas in the comments!
Additional resource: Successful Branching Model
