Support for (feature) branches

Comments

5 comments

  • Avatar
    Marco Abis

    Hi Manuel,

          everything is possible but we don't want a tool that by trying to be everything to everyone ends up being not very good at anything.

    Further support for various kind of branching comes up often, with lots of pros and cons. I personally think we should try and be more helpful to people who currently have branches and are slowly trying to move away and I agree we are not there yet.

    When in doubt though we revert to what we believe are the current "best practices" (I kind of hate the term!) and we definitely believe in trunk based development and as times goes by more and more people are joining us: Google, Etsy, Facebook, Netflix, Amazon all use trunk based development (we can argue about the Netflix / Amazon model, but we still think it's fundamentally trunk-based development if you're actually doing SOA correctly).

    There is also a great example of doing trunk-based development with Git at scale on embedded systems (firmware) on a team of 400 people distributed across 3 countries: http://www.amazon.com/dp/0321821726/ - I discuss it in my talk "adopting continuous delivery" http://continuousdelivery.com/talks/#adopting for slides and video. There is a nice diagram in the slides (taken from the book) which shows how the HP LaserJet Firmware team made it work.

     

    So I guess what I'm saying is: we've been thinking about this a lot but won't come out with something unless we feel it is consistent with our vision for Go.

    Thanks for the feedback

    Marco 

  • Avatar
    Manuel Pöter

    Hi Marco,

    thanks for your comment!

    I get your point! Trunk based development definitely has many pros, but I think there are also many situations where it is legitimate (if not even necessary) to use branches - especially if your are dealing with legacy code.

    We often have special refactoring branches to improve the "historically grown" code. Sometimes we want to replace old components with completely new ones or try new experimental algorithms. I know that in a "perfect world" with a good code base these things should be possible by using "feature toggles" or "branch by abstraction", but again the legacy code often causes troubles.

    One thing I don't understand is how you handle release branches with trunk based development. We create a release branch 2 weeks before the release (= code freeze) and in these 2 weeks we perform all kinds of manual release tests. (We are currently trying to automate most of the tests and to integrate them into our build system.)
    If a few weeks later we have to release an important bugfix we can fix it on the release branch (and merge it back to default) and let the build system create a new release - unaffected by any changes on the default branch (trunk). How can this be done with Go without a branch?

    We are working with 1 week sprints and I know that with real continuous delivery we would have a new release every week so there would be no need to make this bugfix in an old release, but instead provide a new release that includes the bugfix. But we are developing a desktop application and we have very conservative customers who wouldn't accept a new release every week. We have 3-4 releases a year and some customers perform their own extensive tests before releasing the software internally.

    However, this is only my view - I don't know how other users of Go think about this. It would be great if you would add better support for branches, but if not I was thinking of maybe writing a plugin (given that Go supports a suitable API ).

    Best regards,
    Manuel

  • Avatar
    Manuel Pöter

    Hi again,

    I've been thinking about this a lot! I've read the book about HP that you mentioned, I've read great parts of the Continuous Delivery book (for the second time) and eventually I came to the same conclusion as you - we should stop using branches and start doing trunk based development.

    In fact I held a TechTalk (largely based on the slides by Jez Humble and Carlos Lopes from slideshare.net) at my company to get my boss and my colleges on board and push the idea of trunk based development and continuous delivery - with great response.

    Best regards,
    Manuel

  • Avatar
    Srikanth Seshadri

    Hi Manuel,

    Thank you for your note. Fantastic that Trunk based development is path you plan to take forward.

    regards

    Srikanth

  • Avatar
    Butes

    amazing

Please sign in to leave a comment.