Compliant equals trustworthy

As your software product grows so do the expectations of its reliability, data integrity, security et cetera. Various actors want to trust you first before scaling up their relationship with you. These actors are plentiful, from the users of your product to other businesses you’re dealing with to regulatory bodies within your industry. At some point, managing these relationships individually becomes so overwhelming that you need to start thinking about a scalable way of proving that those actors can trust you. You design or adopt a system of standards and best practices regarding quality, security, privacy, data integrity and other attributes of software that people can trust. Then you design a system of rules that enforce those best practices, in a scalable way. You’re ensuring and enforcing compliance with the standards. The evidence of the existence of such processes can and should be used by you to prove to other people that your product is worth their investment of time, money and data.

This all has been pretty abstract so far, so let’s focus on one aspect of the software development lifecycle and explore it further: using a version control system (Git) and project management system (todo.space) to increase your compliance with some of the software development standards.

Traceability of changes

One of the standards you will need to follow is the traceability of changes. For every change that eventually reaches production there should be a clear way of telling:

  • Who did the change?
  • Who requested it?
  • Does the change correspond to what was requested?
  • Did it pass the quality gates?

The utility of knowing the answers to these questions should be evident: you don’t want random people to change your product and leave no trace behind. What if the change is not in line with the vision of the product? What if it introduces a critical security vulnerability? What if it simply corrupts or destroys your customer’s data? You want to ensure these things don’t happen as the inability to do so erodes the trust in your business and can ultimately lead to its failure. Having definitive answers to these questions becomes an evidence of you following the standards and enforcing compliance. Some of the certifications like SOC 2 or ISO 27001 are impossible to obtain without proving these.

Documenting changes in the project management tool

Every change should be requested by someone, even if it is the same person who does the change. There is no better way of storing these requests for changes than documenting them in a project management tool like todo.space. To document such a request you should simply create a task with a descriptive name under the appropriate board. If there is more nuance than fits into the task name then add necessary details in the description of the task. This task now captures the information about the requester and the intent of the desired change.

Tracking the changes in Git

I’m going to assume you are using a source code management system (SCM) like Git for your project’s source code. There is virtually no compelling reason to not use an SCM in 2024, even for the simplest of pet projects that only exist on your laptop.

With Git answering the “who made the change” question is easy: every change to the source code in such a system always comes with the username of the person who made the change.

Connecting Git to todo.space

We now have means of tracking the changes in Git as well as tracking the requests for changes in todo.space. The next question is: how to correlate changes in Git with tasks in todo.space so that every change in Git corresponds to the task in todo.space?

The most common approach in the industry is to have the commit message in Git contain some form of ID that links back into the project management system where the task can be found by this ID. The following format of the commit message is one the more common: [Task ID] [Task title]. In a real project, the commit in the Git log could look something like this:

commit c6b94287122903e9461e57686a3859fb71fa91e9
Author: Your Name <[email protected]>
Date: Mon Nov 13 21:26:08 2023 +0100
DEV-123 Implement performance improvement so that calls for Acme corp. don't time out.
Here, just reading the commit message alone already provides some explanation of the change and DEV-123 links to the task ID in the project management system. Further details about the change and its requester can be found there.

todo.space makes this process almost effortless by giving you the Git integration tool in the task editor in the enterprise plan:

Task editor, git integration tool with generated console commands

Use the second field to get the generated console command that will create a Git branch named after your task as you begin working on source code changes. Once the changes are done and you are ready to commit them, use the third field to get the generated console command with a properly formatted commit message.

Doing these simple steps will ensure the connection between changes in Git and tasks in todo.space and will make it much easier for you to prove the traceability of all changes that reach production.

Enforcing the best practice

One final question to answer is how do you enforce this correlation between commit messages in Git and tasks in todo.space so that you can prove you always stay compliant with the best practice?

For this, you have to ensure that ill-formatted commits lacking links to tasks in todo.space cannot reach production. This is entirely dependent on your Git hosting like Github, GitLab or BitBucket and the way your continuous integration is set up.

Usually, these services contain settings such as:

  • protected branches where nobody without explicit permissions can push commits to
  • commit naming rules — these could help enforce the commit message format with regular expressions and such
  • Git pre-receive hooks that run on the server and can reject pushes that contain ill-formatted commits to the repository
Additionally, your continuous integration can be set up to inspect commit messages and fail the build if it detects commit message formatting errors.

Paving the way to certifications

In conclusion, spending some time implementing these measures will greatly strengthen your compliance posture and will make certifications like SOC 2 or ISO 27001 easier to obtain. Having these and other certifications will help grow your product by opening it up to the more demanding businesses and customers.

Buff Doge vs. Cheems Meme, SOC 2 compliant vs Editing files in the production server