docs
docs copied to clipboard
Published
20 hours ago •
pulumi
pulumi
Best Practices: Authoring, Testing, and Publishing Components
Create a page in the docs for best practices around the full lifecycle of authoring components.
Some topics to cover:
- What should go in a component? What makes for a good abstraction? (coherence, needs to actually abstract something)
- What's the local dev process/SDLC for developing components? How to test locally?
- What should the outputs of a component be? (typically, all of the resources in the tree)
- What should CI/CD look like for components?
- How to ensure that changes are not breaking? (using Pulumi's integration testing framework, creating a test bench locally, or changing the linking to local copies the component)
- How to roll out changes that are necessarily breaking?
We should note that the what we advise is a way of doing things that we are confident works, but is not necessarily optimal for every organization.
From a duplicate issue:
- When do you need a component? (When there's multiple downstream repos/teams consuming it.)
- How should I structure my repos? (Usually all templates in 1 repo. Components have a couple of options.)
- How do you test a component locally, mostly to ensure no breaking changes, recreates, etc.? (By creating a Pulumi program in the same repo that serves as a test bench, or by linking to a local copy of the components from your templates repo.)
- How do I version my components? (Semantically.)