Since 9 months we are working on a large app project. We have built it from scratch and will continue developing it throughout the year with about 2.5 FTE. I am very proud of this project. Because of it’s scale, because the whole team can learn from it every day and because it gives Lightbase the opportunity to grow professionally.
At Lightbase, we want to improve our development processes constantly. So we are curious to hear your ideas and feedback on how we organize the development of our biggest app project today. Here we go:
We use GitLab’s issue board to manage our tasks. Each bug, feature or other type of task is turned into an issue. Issues usually are put in the backlog, from where they move to sprint (a scrum term, we actually mean “priorizited backlog”), to doing and finally to done. Kanban style.
Each issue in is assigned to a responsible team member and labeled, like “bug” or “feature”. This helps us track the status of each issue at any time so we always have a clear overview of what we’ve done, what we’re working on and what’s next.
Our error tracker, Sentry, is also worth mentioning. All software contains errors and bugs. Without a proper error tracking framework, you are totally reliant on bug reports from humans to find out about their existence. A good error tracker can automatically send those bugs reports + useful debug information in a way that a human can’t.
Because Sentry has an integration to GitLab, we can turn errors into issues with the click of a button.
In order to painlessly co-work on the same codebase we use Git (also on GitLab), the industry standard version control system. A version control system makes it possible to merge code written by different developers together, and much more.
One of the best things about version control is that it enables you to a snapshot of the codebase at a certain moment in time, and being able to track what has changed. This is very helpful for fixing bugs, because you can see when they were introduced and trace what caused them.
We use Bitrise for our build automation. This process can be initiated with very little effort: by moving a snapshot of the code to a certain spot in our version control system.
In the build process, several things are done for us. The most important is turning our code into an app that can run on a phone. But we have done some more magic, for example:
- Uploading the app to the App Store and Play Store
- Sending an email with a summary of all changes (Git commit messages)
- Tagging our codebase to mark the release
Recently we have decided to introduce weekly release cycles. This means that if all goes well, a new app version will appear in the App Store / Play Store each week. The great advantage of this setup is that bugs are fixed rather soon after they are discovered and that the differences between two versions are not enormous, making it easier to review the changes and fixes. We use the following schedule:
- Ship a test version on monday
- Tests during the week, we do hotfixes asap for issues that come up
- The same version, but with the hotfixes, will be released on friday
It will require quite some discipline from the development team and the client to not get tempted to cram in new features and changes during the week. Rule of thumb: only hotfix newly introduced bugs and bugs that take only a short time to fix.
Bugs that are already live will remain live if you postpone the release, so why not just release the current changes and fix the old bug in the next cycle.
We communicate with the client’s team in many ways. Mostly Slack, e-mail and phone for day-to-day stuff. But we have some channels that we find particularly helpful:
The weekly development digest: a summary (sent with MailChimp) of what we have been working on, what we will be working on, major issues that we are aware of and last bot nut least, things we have requested and yet need to receive, like a design or specification.
The weekly product meeting: a 30–60 minute walkthrough with all development leads involved. To update each other on the business side, development and to smoothen the cooperation. As the different teams are based in separate locations, separate countries even, we find it useful to meet in person every months or so as well.
The service desk: a special e-mailaddress with a direct integration to our kanban board. Everyone who know this e-mailaddress can send in issues, which are put straight into our issue board, ready to be addressed. We can communicate with the sender directly from the issue board in case we need clarification or if we have an update on the issue.
In the near future we would like to embed the following in our development process:
- Automated testing: we have some ideas, but are not yet convinced of the benefits vs. time investment. Not at this stage at least. Perhaps we should have created tests from the beginning.
- Analytics: we use Firebase to track how users interact with the app. This is valuable information for the UX team, so we’d like to actually use it for that purpose. Preferably in some automated way, like a monthly usage report.
Thanks for reading! I am very curious to hear your thoughts.