How Taxfix doubles referrals with Voucherify, Braze, and Amazon Incentives
0
Days
0
Hours
0
Minutes
0
Seconds
Show me how
2022-10-19 5:00 pm
arrow pointing left
go to TECH
Technology
Migration to Monolithic Repository Without Code Freeze
Mike Sedzielewski
Mike Sedzielewski
November 13, 2017
Share it on Twitter
Share it on Facebook
Share it on LinkedIn
Share it on Twitter
Share it on Facebook
Share it on LinkedIn

Migration to Monolithic Repository Without Code Freeze

Why go monolith?

2 years of Voucherify development gave our code base enough time to outgrow a single project and become a handful of interconnected services. Naturally, in the course of building our platform, we’ve noticed a growing number of code used in several places - popularly called “commons”. So far, we’ve simply duplicated the code where it’s needed. This is clearly the fastest way and we chose it deliberately because our dev team iterates fast.

But there comes a time when duplicating and maintaining the commons becomes troublesome and actually slows down the iteration speed. The burden of remembering all the places where the util is used is just too high. Therefore we’ve brainstormed how to solve the issue and actually ended up with 2 solutions.

The first one is to create a module repository. E.g. wrap projects into NPM modules, introduce a versioning scheme, and set up a private module repository. Although this approach has some indisputable benefits, it’s not a 100% fit for our case. Here are the bullet points from our meeting:

  • With so many repos, somebody has to learn how to maintain (and do so) the NPM repo. With monolithic repo, no dependency management issue, no manual upgrading module versions
  • Code reviews become easier with monolithic
  • Navigation in the source tree and projects becomes easier too
  • Testing and continuous delivery becomes easier - you know you have a consistent state at commit X

Basically, deciding to take the mono path is about having the “commons” issue solved and keeping the iteration pace at the same level. Additionally, we’re still a small, lean team - working on a single project as a matter of fact. That’s why there’s little chance that our developers will waste time on understanding irrelevant pieces of code. It’s quite the opposite, everybody should be watching every change. For the very same reason, we don’t have to introduce any access control measures.

So, we agreed it’s a good move and then we started wondering how to execute the transition in a way which doesn’t block ongoing development.

Migration process

The transition turned out to be super smooth. We’ve kept the commit history, even with the commit hashes unchanged. This was achievable with a single git command - git subtree. The procedure looked as follows:

1. Putting the repos into a single one.

{{CODE}}

git subtree add --prefix=project-a git@github.com:voucherify/project-a.git master

git subtree add --prefix=project-b git@github.com:voucherify/project-b.git master

...

{{ENDCODE}}

2. Changing the deployment process so that it handles the new “commons” properly (changes in Dockerfile, Procfile, and shell scripts which I won’t be discussing in this article; if you’re interested, let me know in comments).

3. Updating the changes pushed in the meanwhile.

{{CODE}}

git subtree pull --prefix=project-a git@github.com:voucherify/project-a.git master

git subtree pull --prefix=project-b git@github.com:voucherify/project-b.git master

{{ENDCODE}}

4. The ongoing work is being committed to developer branches on a particular repo (also, for the sake of simplicity we have merged all awaiting pull requests to master).

5. Migration of branches from multiple repos, an example for project-a repository.

{{CODE}}

export BRANCHES=$(cat <<HERE

development-branch-1

development-branch-2

development-branch-3

development-branch-4

HERE

)

for branch in $BRANCHES

do

   echo "============== copying ${branch} ============= "

   git checkout master

   git checkout -b $branch

   git subtree pull --prefix=project-a git@github.com:voucherify/project-a.git $branch

   git push -u origin $branch

   git checkout master

done

{{ENDCODE}}

6. In the meantime, developers clone the new monolithic repository and reconfigure the IDEs correspondingly.

7. When a “merge master” gives a signal that he migrated all developer branches, developers can check out remote branches with the following command: 

{{CODE}}

git checkout -b branch_name origin/branch_name

{{ENDCODE}}

8. That’s it, Voucherify runs on the monolithic repository from now on.

Summary & future enhancements

It’s been a month since we performed the migration. By getting easy-to-maintain utils at their fingertips, the team has increased productivity. They are also happy to have only a single instance of IDE running instead of 5 (browsing search results becomes a bit harder though). Now, the next improvement is to extract more “commons” that will make building features even faster: modules like commons-auth or other business-related stuff.

Share it on Twitter
Share it on Facebook
Share it on LinkedIn

Join our newsletter

By registering, you confirm you have read and agree to the Subscription Agreement, and to the storing and processing of your personal data by Voucherify as described in the Privacy Policy.
Before you send us your data, you must become acquainted with the Privacy Policy where you will find information on the personal data controller, your rights and our obligations, the purpose for which your data are processed and any other information which relates to the protection and security of your personal data.
Thank you for subscribing to our newsletter!
Something went wrong while submitting the form.
Close

We’re constantly growing

and we need your help!