The CI/CD and DevOps Blog

Our journey to microservices: mono repo vs multiple repositories

Microservices are currently the hottest topic in software development. The concept is simple: Break down your application into smaller pieces that each perform a single business function and can be developed and deployed independently. These pieces, commonly called services, can then be assembled into an application using some flavor of service discovery like nginx or consul. The microservices approach is considered the architecture of choice for teams that want to build scalable platforms and efficiently and rapidly innovate on them. 

As infatuated as I am with this architecture, our journey to microservices was a long and winding road. It has finally led us to a version of the architecture that gives us the scalability and agility we require as a business. I want to share my thoughts, experiences, and lessons learned in a series of blogs around this topic so you may benefit from our experiences. Also, I would love to get your feedback or comments on our approach.

When you start moving to microservices, the first question before you write a single line of code is: How do you organize your codebase? Do you create a repository for each service, or do you create a single ‘mono repo’ for all services? The two approaches are illustrated below:

How to link GitHub and Bitbucket accounts

Two among the most popular source control providers are GitHub and Bitbucket. Both these providers offer free repositories and it is not uncommon for software teams to have few of their projects on GitHub and few others on Bitbucket. So if you are a developer who has accounts with both GitHub/Bitbucket and looking to run Continuous Integration on projects hosted on both of these source control providers, this tutorial will help you acheive it in an easy way.

First, let's take a brief look at how source control providers are used. Software developers use web-based, hosted source code systems for software projects, to leverage functions such as distributed revision control, bug tracking, source code management and wiki-based documentation. The source code repositories store large amounts of software source code, kept either publicly (for open source projects) or privately and enable multiple developers to collaborate on the code.

Running CI on a Node.js application hosted on a private repository

In my previous blogs, I completed running a basic Continuous Integration (CI) on a Node.js app hosted on a public repository. Next, I configured a simple unit test for the Node.js app to check for errors each time I did a code commit. 

In this tutorial, I'll cover running CI for the same Node.js application, if it were hosted on a private repository. Hosting code on a private repository source control system is the common way developers/teams operate during software development. The overview of the work flow is to sign in using source control provider credentials, authorizing a one-time access to private repositories, enabling the project, configuring the shippable.ymlfile, completing a successful CI run for the Node.js app.

Running Continuous Integration on a Node.js app

Continuous Integration (CI) is a development practice that requires developers to integrate code into a shared repository several times a day. Each check-in is then verified by an automated build, allowing teams to detect problems early. By integrating regularly, you can detect errors quickly, and locate them more easily.

Shippable's CI platform supports different source control providers, languages, platform, notification providers, Docker registry services, container services and IaaS/PaaS providers for an end-to-end application delivery pipeline. In this tutorial, I'll go over basic CI for a simple Node.js app. The work flow includes sign up, enabling the repository that hosts the Node.js app, creating a yml.file that instructs Shippable on the details of running CI & completing a successful CI build.

How to use Shippable CI with GitHub Enterprise

Many enterprises are looking to combine the benefit of Git-based repos with company requirements of on-prem code hosting. Today's GitHub  announcements of a number of new enhancements to GitHub Enterprise are a great step forward for enterprise-grade repos in an on-prem world. Shippable supports GitHub as both a service as well as the on-premise GitHub Enterprise. Here are instructions to connect Shippable to GitHub Enterprise.