We used to have local development using serverless offline, before we deployed it into the cloud. However, due to limitations of local development, and the differences between local and the cloud environments, there was effort needed to ensure similarity between emulated local and cloud environments.
Solution
This PR removes lingering local emulation of our cloud services that we no longer intend to use.
Additionally, site launch cloud infra will have staging, production environments. If you wish to develop in an isolated cloud environment, simply create your own version of the infra in the cloud. eg: npm run deploy:dev -- --stage kishore-test.
Eng Decisions made
Notice that the package.json has a source ../.env before running the sls deploy command. I opted to use our .env file at the project root rather than creating a separate .env file at /microservices/.env for the following reasons:
Lesser overhead to maintain by keeping all of our env in one singular folder. The values used for a potential /microservices/.env will be a subset of the as the current .env files, so any changes to .env would need to be repeated for /microservices/.env.
Serverless framework is smart enough to only export the variables that are required to run in the script
More intuitive to have a .env in the root folder only rather than at multiple locations
Breaking Changes
[ ] Yes - this PR contains breaking changes
Details ...
[X] No - this PR is backwards compatible
Tests
Run npm run deploy:dev -- --stage <your-name>-test
Verify that new state machine environment has been created
Run npm run destroy: dev -- --stage <your-name>-test to destroy newly created environment
Other notes:
Currently we have SiteLaunchStepFunctionsStateMachine-<some-gibberish-string>. This is currently being used for our site launch process with ops. Will be depreciated soon to directly use SiteLaunchStepFunctions-prod in a separate PR.
Problem
We used to have local development using serverless offline, before we deployed it into the cloud. However, due to limitations of local development, and the differences between local and the cloud environments, there was effort needed to ensure similarity between emulated local and cloud environments.
Solution
This PR removes lingering local emulation of our cloud services that we no longer intend to use. Additionally, site launch cloud infra will have staging, production environments. If you wish to develop in an isolated cloud environment, simply create your own version of the infra in the cloud. eg:
npm run deploy:dev -- --stage kishore-test.Eng Decisions made
Notice that the
package.jsonhas asource ../.envbefore running thesls deploycommand. I opted to use our .env file at the project root rather than creating a separate .env file at /microservices/.env for the following reasons:/microservices/.envwill be a subset of the as the current .env files, so any changes to .env would need to be repeated for/microservices/.env.smartenough to only export the variables that are required to run in the scriptBreaking Changes
Tests
npm run deploy:dev -- --stage <your-name>-testnpm run destroy: dev -- --stage <your-name>-testto destroy newly created environmentOther notes:
Currently we have
SiteLaunchStepFunctionsStateMachine-<some-gibberish-string>. This is currently being used for our site launch process with ops. Will be depreciated soon to directly useSiteLaunchStepFunctions-prodin a separate PR.