How to organize a mono-repo in CDK to have a mono-stack but also individual services can still be quickly deployed individually?

0

Is there a documented pattern for this?

Mono-repo with multiple services, some small, some large.

Goal is to have the ability to fully deploy from an empty account in some environments e.g. full CI/CD nightly build, but also be able to self-service deploy individual small services in developer environments.

Current state of full deployment is some spaghetti bash-docker scripts that invoke multiple CDK, Cloud Formation, SAM scripts (thankfully no Terraform).

I want to consolidate this into a main CDK app at the top, so the full build becomes as close as possible to a simple git clone monorepo && cd monorepo && cdk deploy

But also a developer should be able to do git clone monorepo && cd monorepo/my-service && cdk deploy and not have to wait 45+ minutes for a full CDK run from the top.

Is there an established pattern for this?

1 Answer
1

Yes, there is an established pattern for organizing a mono-repo in CDK to achieve both full deployment capabilities and individual service deployments. This approach combines the use of multiple stacks within a single CDK application and leverages the concept of nested stacks.

Here's a recommended approach:

  1. Create a main CDK application at the root of your mono-repo. This will serve as the entry point for full deployments.

  2. Organize your services into separate directories within the mono-repo, each with its own CDK stack definition.

  3. In the main CDK application, import and reference all the individual service stacks. This allows for a complete deployment of all services when needed.

  4. Use nested stacks to modularize your infrastructure. Each service can be defined as a nested stack, which can be deployed independently or as part of the larger application.

  5. Implement a flexible structure that allows individual services to be deployed separately. This can be achieved by creating separate CDK entry points for each service.

  6. Use environment variables or configuration files to control which stacks are deployed, allowing for flexibility in deployment scenarios.

Here's a basic structure you might follow:

monorepo/
  ├── bin/
  │   └── main.ts (main CDK app entry point)
  ├── lib/
  │   ├── parent-stack.ts (parent stack that includes all services)
  │   └── shared-resources.ts (shared resources across services)
  ├── services/
  │   ├── service-a/
  │   │   ├── lib/
  │   │   │   └── service-a-stack.ts
  │   │   └── bin/
  │   │       └── service-a.ts (entry point for individual deployment)
  │   └── service-b/
  │       ├── lib/
  │       │   └── service-b-stack.ts
  │       └── bin/
  │           └── service-b.ts (entry point for individual deployment)
  └── package.json

With this structure, you can achieve your goals:

  1. For full deployment: git clone monorepo && cd monorepo && cdk deploy
  2. For individual service deployment: git clone monorepo && cd monorepo/services/service-a && cdk deploy

This approach allows for both comprehensive deployments and quick, individual service deployments. It consolidates your infrastructure into a single CDK application while maintaining the flexibility for developers to work on and deploy specific services independently.

Remember to use proper IAM roles and permissions to ensure that developers can only deploy the services they're responsible for. Also, consider implementing a CI/CD pipeline that can handle both full and partial deployments based on the changes detected in the repository.
Sources
Automatically detect changes and initiate different CodePipeline pipelines for a monorepo in CodeCommit - AWS Prescriptive Guidance
Deploy multiple-stack applications using AWS CDK with TypeScript - AWS Prescriptive Guidance

profile picture
answered 2 months ago
profile pictureAWS
EXPERT
reviewed 2 months ago

You are not logged in. Log in to post an answer.

A good answer clearly answers the question and provides constructive feedback and encourages professional growth in the question asker.

Guidelines for Answering Questions