We have a skill deployed to, certified, and live in production. This is a custom skill with an AWS hosted lambda function. We haven't touched it in some time. In v1 of the API we were able to support deploying the skill to multiple developer profiles. Each had their own Alexa developer console account and we shared our corporate AWS account (or the developers used their own by configuring their ask cli appropriately). We are running into an issue in v2 though.
In v1 -- The skill.json file had a section called "apis.custom.endpoint" and under that we used a property "sourceDir" that pointed to our lambda custom directory. Nothing in skill.json was unique to any of the developer profiles. The ".ask/config" file had a section for each developer profile that would ultimately contain the ARN of the deployed lambda for each developer. We were simply able to deploy via a "ask deploy --stage <stage>" where "<stage>" was our developer name, test or production. Everything worked well.
We then upgraded to v2 of the API. What we are seeing now is the following:
ask-resources.json -- we are able to craft this file to support our multiple developer profiles. It contains pointers to the skill.json and lambda code location. No problem with this file.
.ask/ask-states.json -- this has sections for multiple profiles as well. It contains pointers to the ARN of the deployed lambda for each profile as well as the last deployment hashes of both the skill manifest as well as the lambda. No problem with this file either.
skill.json -- this is the file causing us fits. It has a required property "apis.custom.endpoint.uri" that seems to require the full ARN to our deployed lambda. Cannot figure out how to properly version this file per profile. Our only thought right now is to use a build script to put a placeholder for the endpoint.uri property and find/replace it from the lambda URI in ask-states.json. Seems like there has to be some better way to do this though. We were also able to mess with the folder structure and duplicate skill.json and our interactionModel/custom/en-US.json file per profile, but that also seems like an unnecessary hack.
What are we missing? How can we easily support deploying our skill to multiple distinct Alexa developer console accounts so each developer can test in their own sandbox?
Also, is there a recommended approach/best practice for deploying the test version of a skill to the same Alexa developer account as the live version?
One last bonus question -- we have never deployed a change to our skill once it was live. What happens if we make a change to the lambda and deploy? Would our skill update automatically or does it have to go through another certification? If so, how exactly does that work since we have a single production lambda function handling our business logic.