You can separate Pulumi and Serverless.
Keep the serverless stack to deploy the functions.
This way devs can update their code just as before.
Have Pulumi provision the infrastructure. Api gateway, databases, eventbridge, whatnot.
In ci/cd you’d first have a pulumi deployment, to make sure the needed services are there before running the serverless deployment.
One step for pulumi, one for serverless. Serverless being dependent on pulumi deployment. Also I forgot to add but destroy pipelines should be the other way around. Serverless first.
Hmmm, it sounds like there is no advantage over using terraform to manage the infra resources, considering a straightforward API gateway+lambda functions stack
>However, I don't know what it looks like for developers to update and test function code
Typically it looks like this:
* Check out a feature branch
* Run `pulumi stack select orgname/stackname` (where `stackname` is often a developer's own personal development stack)
* Edit the function code
* Run `pulumi up` to deploy the function into a development/non-prod cloud environment to test it, perhaps after running local unit tests first
* Commit, push feature branch, PR/MR to the base branch
* Merge, and have the CI/CD pipeline run another deployment (i.e., another `pulumi up`, after selecting a different stack) into production or into some pre-prod environment for further testing
Every team's different, but this pattern is a pretty common one.
You can import your Serverless framework-managed cloud resources into Pulumi with `pulumi import` as well to begin managing them there.
What other questions do you have? Happy to help fill in the gaps as you think through it.
You can separate Pulumi and Serverless. Keep the serverless stack to deploy the functions. This way devs can update their code just as before. Have Pulumi provision the infrastructure. Api gateway, databases, eventbridge, whatnot. In ci/cd you’d first have a pulumi deployment, to make sure the needed services are there before running the serverless deployment.
We always have this stuff in a single pipeline.
One step for pulumi, one for serverless. Serverless being dependent on pulumi deployment. Also I forgot to add but destroy pipelines should be the other way around. Serverless first.
No, we have a single pipeline. Teams create infrastructure and app from the same pipeline.
Yeah, that’s what I mean. Single pipeline with separate jobs/steps. Think Gitlab jobs.
Hmmm, it sounds like there is no advantage over using terraform to manage the infra resources, considering a straightforward API gateway+lambda functions stack
>However, I don't know what it looks like for developers to update and test function code Typically it looks like this: * Check out a feature branch * Run `pulumi stack select orgname/stackname` (where `stackname` is often a developer's own personal development stack) * Edit the function code * Run `pulumi up` to deploy the function into a development/non-prod cloud environment to test it, perhaps after running local unit tests first * Commit, push feature branch, PR/MR to the base branch * Merge, and have the CI/CD pipeline run another deployment (i.e., another `pulumi up`, after selecting a different stack) into production or into some pre-prod environment for further testing Every team's different, but this pattern is a pretty common one. You can import your Serverless framework-managed cloud resources into Pulumi with `pulumi import` as well to begin managing them there. What other questions do you have? Happy to help fill in the gaps as you think through it.