Git has become a favourite software developer tool and for good reason. Developers love the flexibility, speed and ability to branch locally and in place. However, Git has its limitations. It is inherently designed for smaller projects and teams. When projects and teams begin to grow and so does the code repository. Git is also not fundamentally designed to support DevOps (which hardly needs an introduction) but let’s remind ourselves this is one of the biggest movements in IT any of us have seen for years.
So is there an answer? Can users continue to use Git but without the organisation losing visibility or control of development projects? Can Git support DevOps? And can it co-exist in peace with other version control tools. Let’s take three of Git’s biggest challenges and then examine best practices around this. It’s important to note that these suggestions aren’t just abstract thinking: we’re seeing a growing number of organisations worldwide adopting these techniques and successfully too.
At first glance, the fact that Git’s protocol for transferring data is very efficient. Dig a bit deeper and performance-related issues tend to crop up over time, usually stemming back to handling large files or large volumes of files. Every clone of every code repository includes every file in the original. Other version management tools support narrow cloning – where the files and folders cloned are limited – but Git does not support that approach. For any project that scales quickly or involves frequent builds, this is a problem.
Git is also not a star performer when it comes to managing large binary code (or assets), leading to bloated, unwieldy code repositories. The situation becomes worse when Git starts calculating or recalculating content hash values, leading to certain commands slowing down to a snail’s pace, while others will happen almost instantly.
One solution is to use a Git management tool that provides some enterprise control – yet still allows Git users to carry on as normal – that does support narrow cloning. Also think about using ‘shallow cloning’: in other words, clone only the latest version of each file instead of the whole history. Using an external store, such as Git LFS, for large binary assets is another idea.
A by-product of all this is ‘Git sprawl’, in other words lots of small code repositories just to keep some level of performance. While fine for small projects, the same cannot be said for larger ones: who wants hundreds or thousands of repositories, particularly since this creates a massive headache for the DevOps guys? After all, DevOps is all about having everything in the right place at the right time, so imagine getting a fresh copy of hundreds of repositories for every single build. That’s a lot of data in transit.
Then there’s the whole issue of branching: what makes sense to individual developers or teams doesn’t make life easy for the DevOps crew trying to keep up with different branching structures across lots of repositories. It’s therefore essential to define – and adhere to – a branching strategy and workflow, built around the nature of the teams involved.
Hope For Hosting
Any organisation taking on Git has to tackle how to host and manage repositories, with the associated security questions that brings, plus increasingly, the impact on DevOps.
Developers want hosting that support simple creation of new projects, preferably with reliable code review tools and an easy way to push their work to the master code ‘branch’ or mainline code. Simple is good, but in this case it doesn’t fit with DevOps need for scalable hosting. Servers can quickly fall over when faced with shorter continuous delivery cycles (not helped by Git sprawl, so look for a Git management system that supports a multi-server topology, able to synchronise across different locations, with clustering and high availability, all of which will really help to achieve DevOps.
It’s vital to choose a Git management system that has been designed with DevOps in mind: traditional tools are more focused on small projects, whereas DevOps means looking at the total big picture.
Then there’s the thorny issue of security: protection of IP is historically not typically a priority among the developer community, plus Git doesn’t offer authorisation, only authentication and there’s a big difference between the two: Git determines the identity of the user, but doesn’t restrict what they can do once they are ‘in’.
The answer lies in having robust roles and permission processes and tools, particularly if some development activities are being outsourced to remote workers or third party firms. Make sure that that the Git hosting solution provides all the security needed, without hindering developers’ flexibility and creativity.
Clearly, there’s a lot to take on board, but given that there are many developers who aren’t prepared to give up Git (and why should they, given its benefits). DevOps is a horse many organisations are now backing as a means to bring projects to market more quickly. The good news is that while there may be some hurdles to overcome, keeping everyone happy: the developers, the DevOps teams and even the IT admins is far from impossible.