I was wondering how your development teams working in a cloud environment (AWS in my case) are testing their solution in the local environment (which in our case is their laptop). Usually it is serverless architecture involving Lambda, SQS, API Gateway; codebase is C# and Java mostly. Do you still use local dev? Or everything is pushed to a dev / preview environment? If local dev is present, which are the tools used? We are facing some complaints about them having to wait for a pipeline run in order to test.. of course we can improve our pipeline DevEx but it seems the complaint is more on the pipeline approach vs local dev rather than purely on the performance, meaning that even if they have available the smoothest pipeline ever, they would like to continue to use local dev as the first testing environment.

We use docker for our local env so cant comment on serverless, but I have seen teams that use serverless use https://localstack.cloud/ for their local

My related opinions: • Initial focus should be on unit tests, preferably following a TDD approach • For things like Lambda, stubbed integration tests can also be used that invoke the Lambda handlers directly. • I would avoid trying to replicate AWS services locally. Some folks have used LocalStack, but keeping that all working can become a chore. • For full “local” integration tests I would get to the cloud asap and use tools like SAM accelerate or CDK watch in order to achieve fast feedback ◦ Be careful that folks are not moving to integration tests too early or for most testing, I think this can be a crutch for not having adequate unit tests ◦ https://aws.amazon.com/blogs/developer/increasing-development-speed-with-cdk-watch/ ◦ https://aws.amazon.com/blogs/compute/accelerating-serverless-development-with-aws-sam-accelerate/

@Leonardo Romanato I think local dev and preview envs are complementary. One question: who wants to get access to those environments? Developers? QA engineers? Product Managers? Others?

@Romaric Philogène Developers (including DevOps) and QA engineers

Ok so maybe Preview Environment would make sense to consider because those environments are shareable with anyone and does not required to install anything. They are basically running in the cloud. Would that make sense?

Yes, make sense

I think whether that will work depends upon how many devs are using that environment and what they are doing with it. Once you have interesting data involved then that environment could become brittle fast, or could be under a state of continual deployment.

we use lambda (and apigw, sns, sqs etc) and we decided to have preview envs for each open PR. We are using cdktf and the ideal cycle is that devs open a clean PR, their env goes up and they work there. It's not as good as it sounds. cdktf is slow and they need to wait 5min to have it running in the github action. We find a middle ground with them manually pushing changes to their PR-env. It is still very slow for their like.

Thanks @Enrico La Cava! The word “slow” is already something that will create a lot of push backs, unfortunately, but I can have a look at cdktf

Our next iteration will be to replace cdktf with pulumi, that we are testing on other stuff and it seems way faster than cdktf (seconds vs minutes). But whatever it is, it will never feel as ok as running a local env. I am right now very much in doubt if I should use lambda for our next project and prefer a more classic, container-based, stack.

Very interesting, thanks

@Enrico La Cava what do you use for your preview envs? Did you built it?

@Romaric Philogène I have a github pipeline with cdktf. Yes we build it internally.

If you have some blog articles/content talking about your integration I’m interested : )

Let me convice my devs to write about it.

We use the serverless framework and CI jobs to deploy a unique environment on AWS Lambda per developer or PR. For local development its more unit test focused in Docker but you wont ever get the full experience if you dont use the cloud.