Skip to content

7: Microservice Build

Prayag edited this page Nov 17, 2023 · 1 revision

CI

  • CI helps to sync the engineers by making sure newly checked in code is properly integrated with existing mainline code.
  • The CI bundles the code into a reusable artifact called JAR in Java.This is the same artifact that is used in CD and Deployment phase of build pipeline.
  • CI also runs static code analysis like Checkmarx and runs end to end tests against the the bundled artifact.

Source code branching

  • Source code branching allows engineers to develop in isolation without disrupting others work.
  • Engineers should be sync with the mainline every often, I recommend end of the day.
  • Syncing with mainline also known as merging or rebasing can be trouble for new engineers.
  • Commit often and merge with mainline with smaller changes(PR).

CD

  • CD provides feedback about the release possibility of each mainline code check-in. "Can it be delivered to production?"
  • Actual Deployment to production can be manual since you may want to verify verify changes manually in UAT before going to production.

Source Code Management

1: one giant repo, one giant build (monolith)

Pros:

  • Few repositories to concerned about.

Cons:

  • If I make one line of change in one micro service, all the other services will get built and verified.

2: Multirepo: one repo per microservice

Pros:

  • Source code for each micro service is stored in one repo.
  • Code can re-used with shared library released as an artifact in artifactory like Frog, Nexus etc.

Cons:

  • Toolings are required if engineer needs to make changes across multiple repos.
  • Changes may requires two commits across two micro services and have to designed around backward compatibility.

3: Monorepo Pros:

  • Code for multiple micro services is stored in one repo.
  • You can have atomic commit that spans across micro services.
  • Each micro service is mapped with its own build script.
  • Ownership can be handled per micro service with CODEOWNERS file in GitHub.
  • Build tree can be defined with build tool like Bazel.
  • Manageable for 10-20 developers.

Cons:

  • Tooling is most important for setting build graphs and cloning only required part of monorepo.