A pain in the Git!

Is Git moving you away from Continuous Delivery?

I like Continuous Delivery (CD), as I’ve said before I believe it is the only way for organisations to keep up with their competitors, or ideally stay ahead of them! The rapidly changing world hasn’t got time to wait for updates; people want quality updates regularly. Gone are the days of 10 years ago where customers would wait months to see changes they’ve paid for. Expectations have changed drastically, without CD companies will fall behind, then be left behind!

This really isn’t anything new, companies are adopting CD, many have been doing it for years. But, as with most things, we sometimes lose focus and drift away from original paths. This doesn’t have to be a negative, when we find an easier way to do something, we tend to do it without thinking on the greater impact. Watching Steve Smith’s presentation – InfoQ: The Death of Continuous Integration – made me think how relevant this is.

My background has been in SVN development, I’ve only started using Git recently. It doesn’t take long to see that branches are a core concept with Git, it becomes very easy for developers to create them. I can see many developers using feature branches without much thought to Continuous Integration (CI) practices. The branches are used until the feature is complete, only pushing to master as the final step. Having been through CD kick-offs and having many talks about the principles of CI & CD it’s worrying when a few drift away so quickly.

Steve mentioned it in his talk, and it should not be forgotten, that trunk based development is a “steep learning curve”. On the whole, CI and CD principles are quite simple, but having complete adoption in development teams is a challenge. Obviously getting buy-in from senior management is a big step, but this unfortunately is only half the battle. I’ve found that the other half of the battle is mindset!

The mindset change can never be overstated, for all stakeholders! For developers though this can mean changing habits that have been ingrained for years, even those who are doing ‘agile’! You can talk about daily check-in’s to master, automated testing, feature toggles, branch by abstraction until you’re blue in the face but it comes down to the individuals to want to change their approach to development.

Understanding the value of CD should be enough for individuals to want to change. As Steve shows in the presentation with HP, less time firefighting, more time for innovation – need I say more?! It’s not about moving away from Git, it doesn’t matter which version control system is used, it’s about how it is used. Any team can be committed to CI & CD, but unfortunately it only takes one person to decide differently and the process breaks down. I fear it will be an ongoing battle, but it’s an important one needs regular attention!

Another essential part is to include this in your hiring process! Do you currently ask candidates on their experience/thoughts on CI/CD? If not, I would recommend starting. Do they know the basic principles of CI and CD? Do they know what a deployment pipeline is? Are they aware of the differences between Continuous Delivery and Continuous Deployment? There are many other questions, the point is to hire people for your teams with the right mindset for CD, otherwise it could be a uphill battle. Growing teams with people who are passionate about CI & CD can make a big difference.

Steve Smith is one of the organisers of the PIPELINE, a Continuous Delivery conference. I went last year and will be going again to this year’s in a few weeks. It’s an excellent conference with good speakers covering very relevant topics. I highly recommend it whether you’re practicing CD or not!





3 responses to “Is Git moving you away from Continuous Delivery?”

  1. Steve Smith avatar

    Hi Steve

    Thanks for the above. It’s good to have positive feedback on a talk. Needless to say I entirely agree with the points you are making!

    As you say, there is no problem with DVCSs Git, Mercurial, etc. – there is a problem with the branching-heavy DVCS strategies people blindly use as a result.



  2. NickB avatar

    > It doesn’t take long to see that branches are a core concept with Git, it becomes very easy for developers to create them.

    Let me redress an injustice and a common myth about SVN which is often mentioned when people compare SVN and Git. Creating, using and maintaining branches in Subversion as easy – and even easier in some cases – as in Git. What could be easier than running `svn copy ^/trunk ^/branches/mybranch`?

    Branches in Subversion are lightweight[1] and SVN user is not limited to one-level namespace as Git users are. Lteams working with Git will encounter problems with concurrent work with large codebase[2]. And what is more, in Subversion you will never lose version-history of a removed branch. But git’s garbage collector will eventually remove all code history of a removed branch. Git won’t act as you expect if your source code and its change history is precious for you[3].

    [1]: https://svnvsgit.com/#branching-myth
    [2]: https://svnvsgit.com/#git-scalability-for-larger-teams-myth
    [3]: https://svnvsgit.com/#git-history-is-not-safe

    1. Steve avatar

      Hi Nick, the blog isn’t comparing SVN and Git, I agree with your comments on SVN (I used it for many years). Although I would say merging & reviews are much easier in Git, which is part of the appeal for many, but this is another topic. The blog is about the strategies promoted by Git to rely on feature branches, I see many quickly lose sight of CI/CD principles because of this. As Git is now so popular it has become a bigger issue.

Leave a Reply

Your email address will not be published. Required fields are marked *