From 1c5c528e62365af0646501a45f470224954dec87 Mon Sep 17 00:00:00 2001 From: brettlangdon Date: Wed, 24 Jun 2015 08:03:43 -0400 Subject: [PATCH] add microcommit article --- contents/articles/microcommits/index.md | 74 +++++++++++++++++++++++++ 1 file changed, 74 insertions(+) create mode 100644 contents/articles/microcommits/index.md diff --git a/contents/articles/microcommits/index.md b/contents/articles/microcommits/index.md new file mode 100644 index 0000000..41cf5c1 --- /dev/null +++ b/contents/articles/microcommits/index.md @@ -0,0 +1,74 @@ +--- +title: Microcommits +author: brett +date: 2015-06-24 +template: article.jade +--- + +A look into the new development methodology of microcommitting. + +--- + +Lately everyone has been talking a lot about +[microservices](https://en.wikipedia.org/wiki/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 +[agile](https://en.wikipedia.org/wiki/Agile_software_development), making +test cycles smaller with +[continuous integration](https://en.wikipedia.org/wiki/Continuous_integration), +making release cycles smaller with +[continuous deployment](https://en.wikipedia.org/wiki/Continuous_delivery), +making applications smaller with +[service oriented architecture](https://en.wikipedia.org/wiki/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](https://news.ycombinator.com/). 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: + +```shell +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. + +Enjoy.