Hotswapping lambda deployments into pipeline stack

[PeterBaker0]

Hi CDK team - thanks for all your work.

I am leading the usage of CDK as part of a small dev team (5-10).

We are in the early stages. I have setup a deployment using CDK's code pipeline library.

As part of the deployment, we are docker bundling lambda packages. This works really well in the deployment pipeline.

However, if we want to quickly debug lambda functions, the ~8-10 minute minimum Code PIpeline deployment time is a real obstacle.

I am aware of the cdk deploy --hotswap flag which is really useful when you are deploying your stack from the command line for quick lamdba function swap-outs for debugging (awesome feature!).

Unfortunately, this doesn't really work (as far as I can see) when using CDK pipelines because there is seemingly no way to specify a particular pre-existing stack which was deployed through code pipelines as the target to hotswap against.

In my app.py, if instead of instantiating the PipelineStack I instantitate the infrastructure stack directly (temporarily) and change the name to match the name of the deployed stack (from the pipeline), cdk diffs inform me that it has found the stack and is comparing against it, but all the metadata and naming is incorrect for the resources because of the different naming scheme used by the pipeline deployment.

Ideal behaviour would be able to --target a pipeline deployed stack from a local dev context enabling A) quick redeployments for dev purposes, bypassing the pipeline B) usage of the hotswapping feature.

Open to any suggestions to increase dev velocity for testing and debugging lambda functions which are dependent on deployed live resources as part of a CDK CodePipeline deployment.

[skinny85]

Hi @PeterBaker0,

there are a few separate things you are asking here:

1. You want to hotswap in a CodePipeline

Unfortunately, this is not something we will support, as hotswapping should not be happening in shared environments that the Pipeline deploys to (but read below for a way if you want to go against our recommendation).

Instead, each developer on the team should have their own copy of the CDK application deployed (ideally, in their own AWS account, for maximum isolation), and iterate on it using cdk deploy MyDevStack(s) (of course, using hotswapping / cdk watch is very much recommended here, to speed up the iteration cycle!).

Once they are happy with how their changes work, only then should they git push (or open a Code Review - not sure how your team operates), and the pipeline will pick them up, and deploy the changes to the shared environments.

Hope this makes sense!

2. You want to deploy locally to the same Stacks your CodePipeline deploys to

This is actually already possible, and doesn't require any dances like instantiating the Infrastructure Stack separately. If you just invoke cdk diff YourStageName/YourStackName (with the correct credentials, of course), you'll be able to manipulate the Stack deployed in the Pipeline that way.

Let me emphasize - this is not something we recommend you do, but you have that option if you want to.

---

Thanks,
Adam

[PeterBaker0]

Thanks Adam, that is very helpful.

I like the idea of having a per Dev reproduction of the infrastructure so that each developer can iterate quickly and then push into the shared stack when ready. I get concerned by the expense of running pay per hour services like databases and containers in this manner.

I did have a very good experience yesterday by spinning up a microservice of the infrastructure I was iterating on from my machine. Using hotswap made that whole experience quite seamless. Then tore it down and moved into pipeline and worked well.

Will have to think more about this and find a balance between expense and utility. Cheers.

[skinny85]

Nice, I'm glad this makes sense! 🙂

Usually, the costs savings are achieved by having different settings for the developer-only Stacks, which make the resources cheaper. See my blog article for an example: https://www.endoflineblog.com/cdk-tips-05-have-a-stack-instance-per-deployed-stack.

[PeterBaker0]

Thanks Adam - blog post was informative!

[github-actions[bot]]

Hello! Reopening this discussion to make it searchable.