Engineering at Labs: Part 2

In the previous article, we have learned about the Tools that we’re using to build software at Labs. Today I’d like to continue the series by talking about project management, code versioning and release management.

Generally, we use agile programming methodologies. We break up our work into different milestones, which get translated to sprints. Ideally our sprints last one week but if there is something particularly difficult, we use two weeks.

1. Project Management

We manage our projects in a fairly standard way. As a full team, Labs has a meeting on Monday at 2:00pm for 30 minutes, where we will discuss at a high level the status of all of our projects. It is a good way for everyone to get together and get the week started.

We divide product development into smaller chunks called milestone or sprints - we manage milestone on GitHub. Each milestone contains almost 2 weeks of tasks in form of issues.

We have another full team meeting every Friday at 5pm. This is to close out the week, where we can discuss at a high level if anyone has not been able to complete their sprint, if people need to finish work over the weekend. After that we spend some time discussing news of the week, other ideas. Again, this is a good way for everyone to get together and have a discussion as a team — in COVID when we were not seeing each other at all, this was important. As we start getting back into the office, we can hopefully do this with tea and snacks etc.

2. GitHub for Developers

GitHub helps us to build, ship and maintain software. We also heavily rely on GitHub’s Projects — an adaptable spreadsheet, task-board, and road map that integrates with your issues and pull requests on GitHub that helps us to plan and track our work across multiple repositories and projects effectively.

Creating a Ticket

To keep track of what goes into product as feature, tweak or a bugfix, we open an issue before start writing a single line of code. At Labs we’re following “Product-first” approach instead of “Code-first”. We make sure when opening an issue, it must have:

Well-written title
Description — mostly it contains business rules and client requirements
ETA — developer gives an estimation when it’s ready to ship
Assignee, project, milestone, tags (helps to filter tickets)

Branch Strategy

A great starting point is this blog post about a successful git branching strategy, which is the preferred method of branch: https://guides.github.com/introduction/flow/. At Labs we follow the same strategy and each of our repository have:

main — represents the latest shipped version of the code

staging/develop — represents the very latest development code. When making bug fixes, starting new feature or a tweak, we should usually create a new bugfix branch from the staging or develop branch.

When creating new branch, branch name would be hyphenated e.g. 
setup-user-authentication, create-voice-campaigns. Previously 
we stuck chore/person-name/short-description or 
feature/person-name/short-description naming convention.

However at this point — GitHub gives a way to create branch name and we’re following that convention too along with kebab-cased naming convention for branches. Navigate to assigned ticket and click on “Create a branch”.

Commit Changes

A commit message is descriptive text that is added to the commit object by the developer who made the commit. It has a title line, and an optional body. Commits should happen frequently in lower-case.

Commit Message Guidelines:

Short (72 chars or less) summary

More detailed explanatory text. Wrap it to 72 characters. The blank
line separating the summary from the body is critical (unless you omit
the body entirely).

Write your commit message in the imperative: "fix bug" and not "fixed
bug" or "fixes bug." This convention matches up with commit messages
generated by commands like git merge and git revert.

Further paragraphs come after blank lines.

- Bullet points are okay, too.
- Typically a hyphen or asterisk is used for the bullet, followed by a
  single space. Use a hanging indent.

Example for a commit message

add CPU arch filter scheduler support
wire-up backend login flow
remove dead-code

References in commit messages

If the commit refers to an issue, add this information to the commit message header or body. e.g. the GitHub web platform automatically converts issue ids (e.g. #123) to links referring to the related issue.
```
revert login to send sms - closes #777
fix infinite-loop - fixes #125 
```

3. Release Management

Our apps release versioning follows a convention of [Major].[Minor].[Bugfix]

Major Release — Whenever we release a significant UI or functional change in the app, we increment the Major version. For example, upgrading from 0.4.4 to 1.0.0 would indicate a major release.
Minor Release — When a fairly visible new feature is added to the product but it’s not a major release, we increment the minor version of the app. For example, if we added in a few new features to the Quick Menu, we might bump the minor version to 1.2.0 Note that we always use EVEN minor release numbers for public release versions. For example, we’d never release 1.1.0 to the public.
Bug Release — Generally when we make a release that just includes bugfixes, or even just a tiny feature, we only increment the bugfix version number. For example, if we started with 1.0.0 as the major release, but then needed to fix a bug that was causing crashes, we’d release a new version of 1.0.1

To summerize, at Labs we follows agile programming methodologies and project management practices. By breaking work into milestones and sprints, utilizing GitHub for seamless collaboration and version control, and adopting a "Product-first" approach through detailed issue tickets, Labs establishes a structured and efficient development process. We emphasis on a well-defined branch strategy, commit message guidelines, and versioning scheme reflects a meticulous commitment to maintaining code quality and managing releases effectively. This holistic approach not only fosters collaboration and communication within the team but also ensures the delivery of reliable and well-structured software solutions to our bespoke clients.