Following on from a previous post, I now had the change log of my project in a JSON file. The next step is making this visible to the team via web site, specifically for our product development manager and lead QA tester. I needed something quick and dirty, so I choose Bootstrap and KnockoutJS which I am familiar with to create a basic web page that loads the JSON file and processes it.

Continuing with the VSCode Editor git log, the first pass simply displays the list of commits in an ordered list (excluding merge commits):

Git Change Log View

This is immediately useful because you can see which commit is linked to which issue number on GitHub, and the view link will take you to the Commit Compare page. However using the git short hash as the title of the panel is somewhat meaningless, as no extra information can be visually obtained.

The next step for our project was to add the version number information on to each commit. This allows us to group the commits into versions, and if we know the version in each environment we can then list those commits/changes in that environment.

Using my current project as an example, we have 3 environments: Dev, Test and Production. The binaries for the website are migrated from one environment to the next in a linear fashion (I’m ignoring hotfixes) for the moment, so we know that the flow will be Development => Test => Production.

Git Change Log Version Control

With this display of the issues, we can now see in one glance which changes have made it to which environment. This view has proved useful both for the development team (to perform spot code reviews on selected commits) and for our product development manager to see where to focus his testing efforts.

Once we had answered the original question, (what changes were in which environment?), we added some other useful features, such as the environment colouring. Red is development, most unstable, and Production is green (most stable) while Test is blue, for the transition. Another useful feature was the count of the differences between environments. “Changes ahead of Live: 6” indicate that there are 6 commits that are in Test that can be pushed to Production. This is rather naive count in that it counts any commit as a change, even those that are unrelated to new features or bug fixes, such as project clean ups, file movements etc. Future improvements could include keeping track of bugs/features/testcases etc if we changed our process to include these keywords in our commit messages.

We also added independent scrolling of each of the columns, so that you can compare each environment. Regardless of the column (environment), each version is coloured based on the “highest” environment it has reached in the deployment pipeline, as shown below. In this case 2.5.2774.0 is in both Development and Test, so in the Development column it is shown in blue. The same applies to the Test and Production columns respectively.

Git Change Log Version Control - environment compare

We have setup our build process to regenerate the changelog.json file on each CI build, and on each publish to an environment we scrape the current version number from the home page to update the versions.json. This keeps this Change Log view updated automatically, so we have added it to our Build Monitors in the office.

In conclusion, I have a few observations:

  • Using git pull --rebase will help keep a linear history (make sure to follow the Golden Rule!), so if you do multiple commits locally during the day, but only push once at the end of the day, all your changes should be in one version. This helps if you want to group a set of commits together for a specific version. Squash might also help here.
  • We are using a trunk based development model (as opposed to a Feature Branch or a GitFlow model), so a version numbering schema works for us. If you are using a different workflow, your mileage may vary!
  • This process should work equally well with the git hashes in place of the version number. However a version number implies a linear order and is more human friendly. (In future, I will attempt to add this implementation to the Viewer, so as it can be used on a git repository that does not yet have the versioning built in.)

The public version (as opposed to the in-house version) of the viewer is available on GitHub. If you have any feedback for me on this post, or want to know more please get in touch.