Skip to main content

Documenting Version Control

I had my mid-year review yesterday, and delighted to have good comments from my boss for my contributions to all of our current projects.  The main thing he highlighted to me is that I should communicate my changes a bit more - perhaps an email/slack message at the end of the day, or better yet - some form of change log.  Definitely a good piece of constructive criticism.

So I woke up this morning ready to find a good method to keep this to my routine, and to be honest, I was fairly let down with the tools that were off the shelf.  A simple Google search revealed mainly just how different groups defined the term, and maybe a couple of templates here and there.  I thought, what is the best way to document changes as well as to link those entries to the respective files and where they were changed.  My target audience is only the small team that I work alongside.

And then it hit me; up until then I had not used GitHub releases, as I was only ever the sole developer on the platforms I was responsible for, and this way I can put a simple Markdown description of what was implemented or fixed.  Found a simple way to do this, even for commits in the past:

  1. Find the commit you want to make the release from; for me I am going to do releases in a weekly format - for changes from a given Friday-Thursday.  Click on the "Browse Repository..." for this point.
  2. Create a new branch; I am personally going to be naming both my branches and releases by the date (yyyy-mm-dd) for the Thursday I am grouping it for.
  3. Now, create your release from here and make the target for the branch you had just created.  Be sure to log all of the changes and fixes you had done for this week/month (however often you would like to do this for)
And presto!  A clearly defined log that points to the exact changes that were made.  You can probably delete the branch after the release had been made, but I'm going to choose to leave it in as another method of referencing the release and its respective branch.

Would be interested to hear how you might document your changes!
Labels:

Comments

Post a Comment

Popular posts from this blog

Running NodeJS Serverless Locally

 So it's been a long time, but I thought this was a neat little trick so I thought I'd share it with the world - as little followers as I have.  In my spare time I've been writing up a new hobby project in Serverless , and while I do maintain a staging and production environment in AWS, it means I need to do a deployment every time I want to test all of the API's I've drafted for it. Not wanting to disturb the yaml configuration for running it locally, I've come up with a simple outline of a server which continues to use the same configuration.  Take the express driven server I first define here: And then put a index.js  in your routes folder to contain this code: Voila! This will take the request from your localhost and interpret the path against your serverless.yml and run the configured function.  Hope this helps someone!
Post a Comment
Read more

question2answer Wordpress Integration

 Today I want to journal my implementation of a WordPress site with the package of "question2answer".  It comes as self-promoted as being able to integrate with WordPress "out of the box".  I'm going to vent a small amount of frustration here, because the only integration going on is the simplicity of configuration with using the same database, along with the user authentication of WordPress.  Otherwise they run as two separate sites/themes. This will not do. So let's get to some context.  I have a new hobby project in mind which requires a open source stack-overflow clone.  Enter question2answer .  Now I don't want to come across as completely ungrateful, this package - while old, ticks all the boxes and looks like it was well maintained, but I need every  page to look the same to have a seamless integration.  So, let's go through this step by step. Forum Index Update This step probably  doesn't need to be done, but I just wanted to mak...
Post a Comment
Read more

Getting all deltas from Auth0

Before I get in to the solution of this article, let me tell you how it started and fill you in on the problem that arose.  I wrote a procedure to get daily deltas of users - those of which who had created/updated their account on the given day (and including the day before for good measure on the GMT timestamp).  The simple search criteria was just the following: updated_at:[yyyy-mm-dd TO yyyy-mm-dd] Simple, right?  the []'s being the dates are inclusive, while using {} would mean exclusively.  Auth0 lets you mix these on either side depending on your use.  While this is all well and good, Auth0 will limit the number of results (even with paging) to 1000 only. So, your first option is that you could have your procedure create a user export job, and then parsing through the results and eliminating those which do not meet your updated_at search criteria.  I can tell you first hand that eventually the amount of users will just get to be too much and cumb...
Post a Comment
Read more