Standardizing the Development Environment of Different Teams in the Same Organization
Using Bit Harmony to share and collaborate on development environments
The fact that multiple teams live under the umbrella of the same company doesn’t automatically mean they’ll be easy to coordinate. From a software development PoV multiple issues can (and normally do) happen when standards aren’t enforced.
Problems such as lack of a common development environment or real understanding of the entire toolset used by all teams. These issues can cause havoc ranging from increased development time to problems during the dev workflow.
The normal way to solve these types of problems would be to enforce a standard toolset for the entire company and then train everyone around them. But what happens when some of these tools are replaced by other, more updated alternatives? Everyone is forced to learn yet another tool.
The thing is, the tools change, but the workflow doesn’t. So why are we focusing on the tools so much instead of abstracting these concepts and making sure we understand them? Let’s take a look at Bit’s latest version and how it can solve these common problems companies face when by having several development teams working in parallel.
But first: What Is Bit?
If you haven’t heard of it yet, Bit is a popular open-source tool (with native integration to Bit.dev’s remote hosting platform) that helps you create and share atomic components. What does this mean? That you can build independent components from scratch or extract sections of your code and share them as independent components on a Bit server (e.g. Bit.dev).
While that sounds an awful lot like NPM, there are some major differences:
- You don’t have to extract the code to share it. You can export a component directly from inside your repository. Bit allows you to identify a section of your code as a component and treat it independently from the rest of your project. This, in turn, helps you simplify the sharing process since you don’t have to set up a separate repo and rework the way you import those files into your project (Bit is most often used as a tool for authoring components from scratch. In that case, the entire project would be a collection of independent components).
- People importing your components (as opposed to just installing them) can also collaborate on them, modify them, and export them back to the registry. This is incredibly powerful if you’re working as a group of teams inside the same organization. That way you’re able to collaborate on the same tool across teams without having to work on a separate project to do it. Importing a Bit component brings down the code and copies it into your working directory (instead of a pesky
npm_modulesfolder where you can’t do anything with it).
And now with Bit’s latest version, team collaboration is easier and faster thanks to additions such as development environments that you can pre-configure and share with everyone.
Having a common development environment across teams
This is to me, one of the major pain points companies with multiple development teams suffer. Not because they can’t have a common environment, but because having it involves a lot of effort. And normally, a very complex solution as well. I’ve seen companies that required around 4 weeks of onboarding time for new developers to get used to working under their standards.
That is all because they have so many different teams and so many custom and complex workflows involving multiple tools. Developers, in turn, are forced to understand every single one of these steps and how to properly use the tools at their disposal.
However, there is a better, easier way. By abstracting all the concepts involved in a developer’s workflow and working environment. Bit has managed to move the difficulty into the realm of a single independent component with pre-configured setup.
This independent component can be shared through Bit’s centralized marketplace and installed by everyone with a single command. In fact, that is only the tip of the iceberg, every team can also contribute to this custom environment. Adding their own flavor or fixes to it, and sending it back to the central repo where everyone can then benefit from their learning is definitely a plus.
This is not a single entity dictating how you have to handle your workflow. Through the use of this method, it becomes a collaborative effort of finding the best and most efficient way of working, using the experience of everyone involved.
Consider the following theoretical use case:
You have 3 different teams working across the company. Initially, they’re all sharing the same environment (version 1.0). However, over time, Team B realizes there is a better way to handle testing, so they update their environment to version 1.1. Here is the kicker: it’s the same environment, the same artifact, only a different version of it. They didn’t have to change tools, update their internal documentation or anything, they just made the changes and versioned their code.
A while later, once they’ve shown everyone how this new version of the environment works, Team A and Team C simply updated their local environments by installing its latest version. That was it. Team B could’ve changed the testing framework, or a configuration file, it doesn’t matter. All three teams are using the same environment and the same tool to handle everything, so the update was effortless and painless.
Knowledge of multiple tools involved during the build pipeline
If I were to tell you how many times I (or someone on my teams) have had problems with Git, I’d have to write a book about it.
And that is but one tool involved in our day-to-day tasks. Our development pipeline is filled with tools we know very little about. I’m not ashamed to say I don’t really know a lot about Docker and I’ve had to use it as part of my dev environment multiple times. That means googling for commands every time something goes wrong
Maybe you’re a Docker expert yourself, but what about Webpack? Or the bundler you’re currently using? How about your linter or your testing framework? Are you sure you know which one you’re using, why and how?
Those are questions you need to ask yourself unless you want to go asking around when things don’t work.
Instead of focusing on writing code, if the dev environment is complex enough, developers end up spending part of their time making them work. Getting every tool individually configured to make them all work together can be a hustle.
However, if you were to abstract all these tools into concepts, such as “testing” or “linting” or “building” you can then forget about the nuances of each individual tool and worry about the workflow. This is what Bit Harmony does, it gives you the tools to abstract all the concepts around your workflow. It lets you issue simple commands such as bit install express without having to worry if your Node project is configured to use pnpm or npm . It lets you write bit build without having to worry about the right command for Webpack.
In fact, it lets you even export your code with bit export instead of having to remember to first “test” it, then “bundle it” and finally “export it”. In other words, it’s not just abstracting atomic concepts for us, but it’s also providing us with re-defined compounded steps.
Handling a growing number of repositories for internally shared code
When you have multiple teams working in parallel, if the technology they’re using is the same, it’s only normal that they’d come up with generic solutions to the same problems.
Different teams will have to tackle and solve the same problems over time. When this happens, normally common libraries start appearing. Having a set of internal tools or frameworks is not strange, especially when the teams have been working in parallel for a while. In fact, not having them would be a real warning sign.
The issue with this, is that the more tools like that you have, the more internal repositories you have to handle, and maintain. Who is in charge of all of that? Who is the owner of framework A when you need to add a feature to it?
Don’t get me wrong, not having these repositories and copy&pasting code between projects would be even worst. However, while Git is great for working on the same code between multiple developers, it lacks some real collaborative features. It’s then up to the company to have a platform around Git, such as Github enterprise or Gitlabs to somehow solve this problem.
However, yet another benefit of making the switch to Bit Harmony is that the concept it has around components allows you to share code with other teams without the need to have and maintain multiple repositories. Thus removing the need to have owners and maintainers of shared code.
With components, you’re able to logically extract a piece of common code from your source and share it across the company. At the same time, other teams can incorporate that code into their codebase, improve on it, and re-share it with a new version. Much like I explained above with the development environment. This in turn means:
- You don’t need multiple repositories, owners and maintainers for each one.
- Anyone can use these components and by handling different versions, they can easily install the one they need.
- Teams can opt out of the ability to change and modify the and simply import the components as dependencies.
If you want to know to use Bit to extract a piece of code from your project and turn it into a common component, check out the following article I wrote for Node.js projects:
While it was written for Node, the steps can be easily extrapolated for any other JavaScript-based project (be it front or backend).
Sharing the work between teams
Finally, a huge hustle in big companies with multiple teams (I’m talking about 5 or more teams here) is that of having hidden gems that nobody knows about and everyone ends up re-implementing every time.
Creating common modules is something JavaScript developers know how to do, but sharing them efficiently isn’t included as part of that skill.
How many times have you been told you implemented a common library that had been already developed by another team? You didn’t know, it’s not your fault! What options are there?
- Going team by team asking if a piece of code is already shared is not the right way to do it.
- Setting up a private NPM registry can be a good option if you’re working with Node.js exclusively. However, this is not optimal when dealing with Front-end. Front-end components normally have a visual part to them that gets lost inside a static Readme.
Bit Harmony uses MDX or plain code (in the JS framework or flavor of choice), to create documentation for each component. It also enables the authoring of various component “compositions” which are instances of a component that demonstrate how it looks and behaves in different contexts (possible or common real-time usages of that component).
When companies grow to a point where there is not one or even two development teams but rather, multiple ones working in parallel, coordinating them and making sure they work efficiently is not a trivial task. By taking care of every single step on the development workflow however, Bit Harmony tries to solve all those problems and simplify everyone’s life.
How is your current workflow looking like right now?
