https://serverless-stack.com/ logo
Join Slack
Powered by
how does one clean up after killing the `start` pr...
# help
s
how does one clean up after killing the 
start
process? just manually delete the debug stack?
j
sst remove
will remove the entire app plus the debug stack.
s
so 
sst remove debug-stack
to cleanly remove the debug stack, I take it. EDIT: nope, that doesn’t work
j
Oh you want to remove just the debug stack?
s
correct. after I kill my debug process locally, I’d be looking for a way to neatly clean up all of that
yarn start
also seems to have modified the main stack too. not sure what it did.
f
Hey @Sam Hulick, just want to chime in here. Beside the debug stack, 
sst start
also replaces the Lambda functions in your stack with a stub Lambda that proxies the request to your local.
You can read more about how it works here https://docs.serverless-stack.com/live-lambda-development
s
ahh makes sense. right, so is there a clean way to unravel that when I’m done working?
f
running 
sst deploy
will deploy the latest Lambdas and infrastructure
s
right.. but the debug stack is still left hanging around
or are we meant to just leave those alone
hmm.. so the dev cycle pattern seems to be: 1. 
yarn start --stage devname
2. work on stuff 3. 
yarn deploy
4. test all changes on dev stack 5. 
yarn deploy --stage prod
sorry for all the questions. 😅 just trying to get a handle on this before we jump in with both feet and use this on a major project
j
Yeah the debug stack is completely serverless, so it’s been designed to be left around.
Yeah the dev workflow is roughly right. Just that 
yarn deploy
will default to the stage listed in your 
sst.json
if you don’t pass in a stage. I think you meant 
yarn deploy --stage devname
in this case?
No worries on all the questions, that’s why we are here!
s
sorry, I realize that wasn’t clear. step 3 would actually be 
yarn deploy --stage staging
. in other words, devs work locally w/ 
start
on their own stacks.. and then all of their changes are deployed to 
staging
stage where (for example) QA can test. and then finally 
yarn deploy --stage prod
to release everyone’s work
I’m not sure why a dev would do 
yarn deploy --stage devname
after running 
start --stage devname
. it’s the same code they were just working on. would there be a good reason for them to deploy to their own private stack? (maybe for others to test.. though the API Gateway URLs are public to everyone already, even if running in local mode)
j
Yeah that makes sense. You don’t have to deploy to your own stage. Though there are some cases where you might want to make sure that things have gotten packaged correctly when deploying. But a test to staging will work as well.
s
perfect. can’t wait to dive into SST more this weekend!
f
Hey @Sam Hulick, just added the 
--debug-stack
flag to 
sst remove
in v1.2.13. You can run 
sst remove --debug-stack
to remove just the debug stack.
this is LONG overdue lol
j
Only 10 months late?
I’m afraid Sam won’t be able to try SST now, since it’s been too long.
s
Too late, I've already moved onto the next hot serverless framework 😂
j
lol
Open in Slack
PreviousNext
Powered by