Search for a command to run...
How to Use Git Submodules to Manage Shared Code, Tasks, and Development Environments Across Multiple Microservice Repositories
Yet another developer, learning new things everyday :)
No comments yet. Be the first to comment.
A little story about why I built something that just remembers what a website said last, so it doesn't matter if that website is having a bad day.
Rediscovering RSS Feeds :)
My Long and Winding Road to Becoming a Vim/Neovim User
Mesmerize Your Audience with a Git Visualization Party Trick
In the world of microservices development, maintaining consistency across different repositories can be a real challenge. It's not uncommon to find duplicated code, configuration files, and development environments across various microservices. However, there is a solution that can help alleviate these pains - Git submodules. In this blog post, we'll explore how Git submodules can be a game-changer for managing shared code, tasks, and development environments across multiple microservice repositories.
Before diving into our journey of using Git submodules to streamline microservices development, let's briefly understand what Git submodules are.
Git submodules are Git repositories nested within another Git repository. They allow you to include one Git repository (the submodule) inside another (the main repository) as a subdirectory. This means you can keep a reference to an external repository within your own repository, effectively importing its contents.
Now, let's embark on our journey and understand why and how we used Git submodules.
In our development landscape, we had multiple microservices, each residing in its own Git repository. While these microservices had distinct functionalities, they all adhered to the same project structure and shared common tasks defined in a Taskfile.yml. Additionally, we used a common Vagrantfile to create standardized development environments across different operating systems.
However, maintaining this consistency became increasingly cumbersome. We found ourselves duplicating tasks and the Vagrantfile across multiple repositories, leading to a maintenance nightmare. Any changes or improvements in these shared components required manual updates in every microservice repository. It was time-consuming and prone to errors.
As we searched for a solution to streamline our microservices development, we stumbled upon Git submodules. They seemed like the perfect fit for our use case.
Our first step was to create a dedicated Git repository called dev-templates. This repository would house the shared taskfiles each separated into different files like docker.yml, go.yml, helm.yml, vagrant.yml etc., with common development tasks and standardized Vagrantfile for creating development environments.
dev-templates as a SubmoduleWith dev-templates ready, we added it as a submodule to all our microservice repositories. This was achieved with a simple Git command:
git submodule add https://github.com/yourusername/dev-templates.git <folder-name>
the folder-name can be replaced with the folder name where you want the submodule to be cloned inside the project.
By doing this, we imported the entire dev-templates repository into each microservice repository as a subdirectory. This effectively eliminated the need to duplicate code and configuration files.
Now, when we needed to update common tasks or the Vagrantfile, we made the changes in the dev-templates repository. Whenever we wanted to pull those changes into our microservice repositories, we executed the following command:
git submodule update --recursive --remote
We added this as a task in our Taskfile.yml in the individual microservices repo. And just like that, all our microservices were up to date with the latest changes from dev-templates.
Our journey to incorporating Git submodules into our microservices development process brought several key benefits:
By centralizing common code and configurations in a dedicated repository, we significantly reduced code duplication across microservices. This not only saved us time but also made our codebase more maintainable.
Updating shared components became a breeze. Instead of manually propagating changes to every repository, we only had to update dev-templates. The submodule update command took care of the rest.
All microservices now adhered to the same project structure and development environment, ensuring consistency and reducing the chances of issues arising from differences in configurations.
Our journey of using Git submodules to manage shared code, tasks, and development environments across multiple microservice repositories has proven to be a game-changer. It simplified our development process, reduced maintenance overhead, and enhanced the overall consistency of our projects.
If you're facing similar challenges in your microservices development, consider giving Git submodules a try. They might be the solution you've been searching for to streamline your development workflow.
By implementing Git submodules, we were able to streamline our microservices development workflow, reduce code duplication, and simplify maintenance. If you have any questions or would like more detailed examples of how to work with Git submodules, feel free to reach out. :)