Open
Description
Description:
The DEV databases were removed and the CDK stack is unable to accept any newly created DynamoDB resources unless they are imported and attached back to the AWS stack.
This is not too dissimilar from what might need to occur during Disaster Recovery, where we need to restore a table from a backup and reattach it to the CDK stack. Much of the information to do so is provided in this AWS Blog Post, although this is quite a manual process.
As per Cam's musings:
- Make a Lambda that runs the CDK code to create the DynamoDB tables, either from scratch or use
cdk importto import manually created/PITR created tables by name. - As a CfnOutput from that Lambda, export the correct table reference to Parameter Store
- In the CDK code that runs with GH actions, import that table reference from Parameter Store before doing anything else
- Use that imported table reference to construct all other resources when
cdk synth && cdk deployis run
Acceptance Criteria:
[Note: Use 'Given/When/Then' format if it makes sense to. Otherwise, a simple checklist that can be tested.]
Development Checklist:
- Create a Lambda that runs some CDK code to create or import DynamoDB tables using
cdk import - Export table's name or ARN from the Lambda stack using CfnOutput
- Store this output Parameter Store
- Update CDK in GitHub Actions to read from Parameter Store at
synth - Modify the CDK stack to import the existing DynamoDB table from Parameter Store if it exists
- Confrim that other resources that depend on the table are using this reference
- Confirm that the stack re-deploys
Dependencies
-
Blocked by
-
Blocking
Relevant documentation as reference
Definition of Ready
- Acceptance criteria are included
- Wireframes are included (if applicable)
- Design / Solution is accepted by Product Owner (if applicable)
- Dependencies are identified (technical, business, regulatory/policy)
- Story has been estimated (under 13 pts)
Definition of Done
- In progress:
- Acceptance criteria are tested (Functionality meets the acceptance criteria defined in the ticket)
- UI meets accessibility requirements
- Unit tests are written
- Work is traceable in GitHub
- PR linked to ticket number
- If needed/required - Dev adds flag/label to highlight any migration steps necessary prior to PROD deployment
- Code review:
- Code is peer reviewed and has passed CI/CD tests
- QA:
- Acceptance criteria are tested (Functionality meets the acceptance criteria defined in the ticket)
- Code is potentially shippable to the production environment
- Functional features have been tested and passed by QA
- UI components tested by designer
- Code is deployed to PROD when moved to 'done' column (unless requested otherwise by PO)
- PO Review:
- Acceptance criteria are tested (Functionality meets the acceptance criteria defined in the ticket)
- Reviewed and approved by Product Owner
Notes:
Metadata
Metadata
Assignees
Type
Projects
Status
No status