From c77bab025dc60bdfb5b1e31a6af848c17da5be8a Mon Sep 17 00:00:00 2001 From: Ari Palo Date: Thu, 11 Aug 2022 17:41:36 +0300 Subject: [PATCH] docs: improve intro --- README.md | 26 +++++++++++++------------- 1 file changed, 13 insertions(+), 13 deletions(-) diff --git a/README.md b/README.md index a1be135..662a6bd 100644 --- a/README.md +++ b/README.md @@ -13,19 +13,19 @@
- - Opinionated CDK Project “Framework” is a set of CDK constructs and utilities aiming to solve many complexities related to configuration, naming, tagging, etc. for multi-account & multi-environment projects that utilize [Continuous Delivery & Deployment](https://continuousdelivery.com/) and [Trunk Based Development](https://trunkbaseddevelopment.com/) with feature branches/environments. - - > Things can get quite complex if you: - > - **Deploy a CDK project into multiple different AWS Accounts**
following best practises and separating production from other environments - > - **Manage all the account specific configurations somewhere**
but it's often hard to decide where to store that information and how to access it - > - **Need to map different environments to specific accounts**
as often you may have more application environments than you have AWS accounts - > - **Adjust your infrastructure code for specific environments**
for example cost optimization or backups often behave differently for production vs. development - > - **Potentially use dynamic & short-lived “feature environments”**
e.g. by triggering temporary deployments on Github Pull Requests with a `feature/` branch prefix - > - **Need to setup well-defined tagging**
as proper tagging helps with cost management and even defining backups - > - **Repeat the above steps for multiple CDK projects**
because let's say you develop a lot of microservices in different repositories - > - >     – Ari Palo, Lead Technologist, Alma Media + Opinionated CDK “framework” with constructs & utilities for: + - deploying multiple environments to multiple accounts (with many-to-many relationship) + - managing account configuration through standardized props (no more random config files) + - querying account and/or environment specific information within your CDK code + - enabling dynamic & short-lived “feature-environments” + - enabling Well-defined tagging + - providing structure & common conventions to CDK projects + - choosing the target account & environment by passing in runtime context: + + ```sh + npx cdk deploy -c environment=feature/abc-123 + ``` + ... which means you don't need to define all the possibile environments ahead of time!