DevOps adoption has grown with the changes in product development lifecycles, but the expansion has not worked out well for companies using the Git code management system.
Git has become ubiquitous for good reason. Most, developers love its flexibility, speed, and its ability to branch locally and in-place for juggling lots of tasks. However, things are a bit different when you stir in DevOps. Here are some specific challenges Git poses for DevOps and suggestions for addressing those challenges.
Performance. Git’s protocol for transferring data over the network is very efficient, so initial DevOps impressions can be highly favourable. But a number of performance-related issues tend to bubble up from the details of Git’s internal implementation over time, especially when handling large files or large numbers of files.
For example, working with content in Git alone is an all-or-nothing proposition, which means every clone of a repository includes every file in that repository. Many users have long desired support for narrow cloning, the ability to limit the files and folders included in a clone/fetch operation, but Git still doesn’t support this feature. Second, Git doesn’t handle large binary assets well. Such content can quickly bloat the size of a repository.
Best Practices:
- Standardise on a Git management system that offers narrow cloning
- Use shallow cloning as much as possible to limit file revisions
- Employ an external store for your large binary assets such as Git LFS
Organisation. The performance problems just mentioned often lead to ‘Git sprawl,’ which refers to the proliferation of small repositories in order to maintain acceptable performance.
Git sprawl may not complicate developers’ lives all that much at first, particularly if care is given to divide content along logical project boundaries. But its burden falls immediately on DevOps’ shoulders because having everything in the right place at the right time is essential for builds, testing and the rest of the development pipeline. Getting a fresh copy of hundreds or thousands of repositories for a single build can be a lot of data transfer, even under the best of circumstances.
Organisations that practice component-based development will have to deal with the additional complexity of handling component versions. There also remains the concerns on overall branching strategy given the need for consistency across all of those projects, components and repositories.
Best Practices:
- Look for ahead for handling large numbers of small (usually < 1 GB) repositories
- Build a branching strategy around the shape of your teams and internal processes
- Use build artefact management systems to simplify component referencing issues
Hosting. One of the key questions any organisation embracing Git must face is how to host and manage repositories, and the resulting answers greatly affect DevOps and information security. Developers want hosting that makes it easy to create new projects, clone or fork and push their work, but this desire for simplicity is often at odds with DevOps’ need for scalable hosting.
Shrinking continuous delivery cycles, in conjunction with Git sprawl, can easily lead to servers failing under the load. Git management systems vary widely in this regard, some offering only single-server topology and others providing clustering and even high availability. A robust DevOps pipeline requires considering all of these factors as well as a plan to handle disaster recovery.
Developers’ wishes may also contradict the need to secure the intellectual property they create. Git’s design offers only authentication, not authorisation. That is, Git offers a mechanism to ensure that the person committing is who he or she claims to be, but it leaves the question of what that person can do entirely to the file system.
You’ll want to consider how to shape your security battlefield to accommodate all the necessary roles and permissions. This is especially true if you’re relying on third-party teams.
Git hosting grows even more difficult for organisations spanning the globe. Be sure your Git hosting solution makes it easy to synchronise work across servers in different locations around the world; anything else is just setting up your DevOps team to fail.
Best Practices:
- Prefer a Git hosting solution with broad scalability options and high availability
- Don’t treat disaster recovery as an option; have a solid plan and exercise it often
- Make sure your Git hosting solution gives you all the security and flexibility you need
