Why did we build NetBox Branching?
Over the last six months, we’ve been hard at work making it easier than ever to use NetBox in today’s increasingly fast changing & collaborative network management stacks. We stood on stage at Autocon1 in Amsterdam in May and let the world know that NetBox Branching would arrive in conjunction with NetBox 4.1, and now it’s here as promised. We’ll be talking more about the process we’ve used in a follow up article, but as with everything we do at NetBox Labs, NetBox Branching was built with heavy involvement from our community.
From our first research sessions, through the Private Preview and then the Public Preview we’ve been overwhelmed with the positivity, generosity and insight we’ve received from the community in helping us to design, evaluate and test NetBox Branching. The dozens of community members who have been involved so far have a very keen understanding of what NetBox Branching is, the problem it solves, and how we’re solving it, but for many in the community this will still be new, so let’s walk through it.
Avoid stepping on each other’s toes
NetBox fills a linchpin function in the network management practices of thousands of organizations worldwide. The way these organizations use NetBox varies. Some companies use it as a view into their heterogeneous network: a single pane of glass through which they can maintain an updated view of not only their on-prem deployments, but also massive cloud real-estate across Amazon AWS, Microsoft Azure and Google Cloud Platform. Others take their use further by driving configuration changes to their network from the data they maintain in NetBox.
The problem that NetBox Branching solves isn’t new. Networks are becoming larger, more complex and they are changing faster. Also, larger networks often have a larger team maintaining and evolving them, or in many cases, a number of teams. What this means for NetBox is twofold: the data is being updated more often, and the number of users (or processes) which depend on the accuracy of that data model is growing too.
This can lead to users and processes stepping on each other’s toes, which can impede progress and frustrate operators just when networking teams are being asked to collaborate more efficiently with one another and with other departments. As it happens, software engineers have been dealing with the exact same problem for a very long time. Their solution? Version control systems.
The first Version Control System was called Source Code Control System (SCCS) and was developed at Bell Labs by Marc J. Rochkind in 1972! If you’ve never heard of SCCS, you may have heard of the more recent incarnations of Version Control Systems: Concurrent Versions System (CVS, 1986), Perforce (P4, 1995), Subversion (SVN, 2000), and the Global Information Tracker (2005), now ubiquitously known and used as “Git”. While the space has seen much innovation, the core insight that makes version control systems key for modern collaboration has remained the same over the last 52 years: collaboration works best when users can work on their own copies of the data, with the ability to compare, and then merge their work with their colleagues’ work.
These individual “copies of the data” are commonly referred to as “branches”. Let’s walk through an example to explain the concepts.
- Two network engineers are working their way through support tickets. They each pick a ticket off the backlog.
- It turns out that closing out their tickets will require that they both make changes to the same object in NetBox. Let’s say it’s a Site object.
- When they start their work, they are unaware that they will be interfering with each other’s changes.
This is not an uncommon scenario and many network teams will recognize it immediately.
How this scenario typically plays out without NetBox Branching:
- They each start working on their change tickets but become frustrated when it feels like NetBox isn’t saving their work. “I just set that to X, why is it now Y?”
- Confused Slack conversations and phone calls ensue, collaboration slows down.
- Eventually they figure out that they are working on the same objects.
And now with NetBox Branching:
- They each open a branch for their work and make their changes there. As they are working they notice a notification telling them that somebody else is working on the same Site object in a different branch. They can also see who that person is.
- A single informed conversation happens, collaboration marches on.
NetBox Branching allows engineers to collaborate safely with full visibility of their colleagues’ work
Small interruptions can really add up, leading to missed deadlines and frustration all round. Enhancing collaboration among engineers making changes to NetBox isn’t the only benefit of NetBox Branching however.
Processes that make collaboration difficult also lead to more errors in the data. As I mentioned earlier, it’s common not only for an increasing number of network engineers to be interacting with NetBox, but also for external processes to rely on the accuracy of that data. NetBox Branching helps teams to prevent mistakes that can have downstream consequences in network controllers, deployment pipelines, SIEMs and elsewhere.
Available in all editions of NetBox
You’ve probably heard us talk about our “community first” core value before, like when we made Diode and Diode Agent available to the community, and our investments in the NetBox Plugin Bounty and Plugin Certification programs. We like to describe our approach as a “virtuous circle” of reinvestment in the open source community. As we increase our technology investments we are always looking for the right balance between community availability and commercial features. We believe that NetBox Branching opens up a transformational new feature family and in recognition of how crucial this functionality is, we’re excited to announce that it is now available to users of all editions of NetBox, including the open source community.
This is just the beginning
You will notice that we’ve made NetBox Branching Generally Available (GA) with the recent v0.4.0 release. Why not version 1.0? Following in the footsteps of open source projects like Docker, Kubernetes and Grafana who delayed their 1.0 release, we know that NetBox Branching will be shaped by real world usage over time. Our 0.4.0 GA means that we are confident that you can run NetBox Branching in your production environments while we are adding a whole host of additional functionality, including…
- GraphQL support
- Branching support in pynetbox
- Branching support in the NetBox Ansible Collection
- Improved conflict resolution to catch similar objects between branches and main
- Formal API support for use in custom scripts
- Plugin Compatibility – We’ve worked closely with the plugin maintainer community to make sure that all NetBox plugins can work with NetBox Branching, and fuller support will continue to arrive as plugins are updated to NetBox 4.1
- And much more…
We are of course looking forward to your input on how NetBox Branching should evolve too. Be sure to start a discussion about any improvements you’re interested in and check out the existing issues to see what we’re already tracking.
Get started today
If you’re a NetBox Community Edition user you can get started with NetBox Branching, as soon as you’ve upgraded to NetBox 4.1.
- NetBox Branching is delivered as a NetBox Plugin and requires no additional tooling. Check out the installation and admin guides on GitHub here: https://github.com/netboxlabs/netbox-branching
- Join the conversation in the #netbox channel on the NetDev Slack: https://netdev.chat/
If you’re a NetBox Cloud or NetBox Enterprise customer, NetBox Branching will automatically be included in your instances starting with NetBox 4.1. As always our Customer Success team will be happy to guide you through the upgrade process. If you have any questions please contact support@netboxlabs.com.
Up next
As we’ve worked through countless insightful feedback sessions with our community members it has become clear that NetBox Branching has applications across the entire network management lifecycle, and we’re going to be talking about those in a series of follow-up blogs over the next couple of weeks. Keep an eye out for a lot of NetBox Branching content that will touch on how we built it, ITSM integrations, how NetBox Branching makes audits easier, working with the branching API and much more.
If you’ve been following all the recent announcements you will no doubt also have heard about our upcoming Change Management family of features for NetBox Cloud & Enterprise, which add an additional layer of compliance and collaboration around NetBox Branching. We’ll have much more to share about NetBox Change Management in the coming weeks.
