Building a CI/CD pipeline for a microservice application

Building a CI/Cd pipeline for microservice application is easier said than done.

On our side, here have been the choices made so far:

  • each microservice has its own git repository (isolation of services)
  • each microservice is designed to be stateless (scalability) – except for db service obviously
  • testing is made of unit-tests (i.e. standalone tests) and integration tests
  • on Git side, we try to keep things simple by doing following:
    • use a feature-branch flow
    • “master” is stable branch, only pushable by Jenkins (our ci tool)
    • each new dev starts with a feature branch and get merged into master through pull-requests
    • upon pull-request creation, i.e. for review & confirmation, feature branch gets first updated to latest master to detect any merge issues, then unit-tests are run
    • if unit-tests are ok, then build is triggered
    • upon successful build, a full set of services is deployed into our servers dedicated at this particular test. All services are deployed through containers using latest master code for their own repository. Our particular new build is then triggered running new code using docker, registering itself and terminating older running (i.e. master based versions). Once all those services are up and running, integration tests are run.
    • upon successful tests, pull-request can now be merged (and same process is triggered once merge reaches master, this time from master branch).
    • all above staging services are brought down after integration runs are done (whether successful or not)
  • once merge to master is done and all testings are green, master is tagged with release number
  • then generated artefacts (build phase) are pushed to artifact repository
  • they are also flagged as available for automatic update through our public api so that installed applications can either automatically update (preferred) or at least display notification that updates are available (less preferred)
  • we always keep a latest-version running on our end, and make sure it got automatically updated to latest version

That’s it!

This setup is probably ok on our app which is of reasonable size, should number of microservices be high, a different approach maybe required to reduce overall integration testing time.

Pipeline version 1

First version to get started:

  • create a docker instance
  • run build step in docker instance
  • trigger unit-tests in docker instance
  • if successful, allow merge

Pipeline version 2

Capitalizes on version 1 and goes one step further:

  • create a docker instance
  • run build step in docker instance
  • trigger unit-tests in docker instance
  • if in master branch:
    • run release step (i.e. store artifact in repository)
    • run deploy step (i.e. deploy locally in always running version + trigger autoupdate on client side)

Pipeline version 3

Capitalizes on version 2 and goes one step further:

  • create a docker instance
  • run build step in docker instance
  • trigger unit-tests in docker instance
  • trigger microservices instances for SIT (all instances from artifactory + activate new version to be tested for microservice of interest)
  • run SIT step
  • if in master branch:
    • run release step (i.e. store artifact in repository)
    • run deploy step (i.e. deploy locally in always running version + trigger autoupdate on client side)

Post a Comment

Your email is never published nor shared. You're allow to say what you want...