One of the challenges that comes with managing any software project is making sure that milestones and deliverables are handled on time. The thing is, it’s hard – from the project outset – to always to predict some of the things that will crop up within each milestone.
If you’re using source control, this can make it difficult to keep your source control in sync with what milestone on which you’re working.
For example, I typically like to work on a milestone, then tag it, and release it. After that, I may do something like `milestone-1.1` or `milestone-1.2` as changes arise, but the more work that arises with each future milestone, and the various impacts it has on previous milestones, the more difficult it can be to truly track each milestone.
So what are we to do?
Tagging or Branching Software Milestones
There have likely been books and extremely long articles written on this particular topic by people who are far smarter than I and who run businesses far larger than, y’know, one or two people.
But that doesn’t mean small businesses or contractors aren’t faced with the same issues.
So, naturally, this raises the question of:
How we do keep our tags and/or branches in sync with milestones as they change throughout the development process?
First off, I’m genuinely interested in hearing how you guys have had to deal with this in your day-to-day work, so feel free to leave notes in the comments, but I’ll share my process for this, as well.
My Branching and Tagging Strategy
So whenever a project is kicked off, the requirements are gathered, and the initial set of milestones are gathered, I’ll start with development, and the process typically goes like this:
- Complete Milestone 1
- Tag the source code as `milestone-1`
- Deploy to Staging
- Gather feedback – any bugs, misinterpretations of features, etc. – and return development
- Tag the source code as `milestone-1.1`
- Deploy to Staging
- …and you get the idea
For the most part, I’ve rarely gone beyond `milestone-1.2` or `milestone-1.3` and I mention that simply to given context to how long a single milestone may be in development.
But then what happens when you hit Milestone 3 or Milestone 4 and something crops back up for Milestone 1 either because of a client request change, or, as terrible as it is to admit, some latent effect of spaghetti code?
At this point, you have `milestone-1.2`, `milestone-2`, `milestone-3`, `milestone-2.3`, and then your source control looks like a mess. It’s hard to make sense of it using this strategy as time passes.
So as much as I prefer the clean tagging and/or branching of `milestone-1`, `milestone-2`, and so on, the truth is that it’s often unattainable given the majority of projects.
An Alternative Strategy
So in several of my recent projects, I’ve ended up using a somewhat of a hybrid approach to what I’ve mentioned above.
In short, the process is as follows:
- Tag `milestone-1` as soon as the initial development is completed
- As feedback is given, then resolve the feedback and tag (or branch) the code into a `YYYY-MM-DD` format
- Repeat the process until the second milestone begins, then repeat
This means that my source control tags end up looking something like this:
I don’t know if this is perfect or if it’s even a good strategy, but it does help me keep my initial milestone deployments in sync, it helps me to coordinate the deployments based on the notes tracked in the project management system, and then when the next milestone has began and undergone the same process.
As I mentioned earlier, I’m still curious as to how you guys manage your source code and projects for things like this, so feel free to offer them up in the comments.
Leave a Reply
You must be logged in to post a comment.