A look into the new development methodology of microcommitting.
Lately everyone has been talking a lot about
microservices, or the idea of
making services as small as possible. Making things smaller seems to be the
trend in development, making development cycles smaller with
test cycles smaller with
making release cycles smaller with
making applications smaller with
service oriented architecture,
and then again making applications smaller with microservices. It would only
make sense then that the methodology of
microcommits will yet again make
things smaller, in this case our commits.
As we all know developers easily lose their train of thought due to many things, like, noise in the office or just the presence of other human beings or sites like hacker news. These distractions mean that sometimes they have unfinished code changes just sitting around locally. In this day and age, that code is a new feature or bug fix, having it just sit around on a developers machine will cost you money! You need those bug fixes as soon as possible to keep your users from rioting and moving to a competitor and you need those new features to attract new users and happy and/or new users means more money for your company.
So, how do we solve this problem? Just like these other methodology changes, microcommitting is a fairly simple idea: make a part of our development process smaller/shorter, in this case our commits and our pushes to the main git repo. The idea is to try and shorten your commit/push cycle for each developer down to as short as possible. Meaning that every developer must be committing and pushing the changes that they have locally at least once within this time frame. I have found that a good time frame to start with is 5 minutes. It may seem like a very long time to start with, but you shouldn’t expect developers to be able to just change their workflows over night, you should start with a high interval like 5 minutes and then slowly you can work them down to about 1 minute, maybe even less if your team is diligent enough.
Microcommitting is only a small piece of the puzzle, however if you pair it together with continuous integration and continuous delivery, then BAM! you have new features and bug fixes going out to your users at least 100 times per day… per developer! Now, how do you like that?
Some may point out a crucial “issue” with microcommitting, which is, if a developer is suppose to be committing/pushing code every minute (or less) how are they going to have time to actually write the code? This is true, if they are manually writing commit messages and running git commands by themselves. However, I have found that microcomitting is most effective with automated commits. If we have automated continuous integration and continuous deployment, why can’t we have automated continuous commits? The easiest way to go about continuous committing is to setup a service or cron on the developers machines which will automatically add all their local changes, commit and push their code. You can use something like the following:
git add . && git commit -m "`whoami` - commit - `date`" && git push
There you have it, the new concept of microcommits. It may take a few hours, maybe a day or two to get your development team up to speed, but once they have their commits down to the minute or sub-minute, you will know be able to notice a huge change in not only user satisfaction, but developer satisfaction as well.