You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I want to know how others are managing multiple environments with the releases created by Github Actions and the release workflow offered by changesets.
I have successfully integrated the Bot and Action into one organization's development process. It was not obvious how to build and store release artifacts (e.g. lambda packages, docker images). I achieved building and uploading release artifacts by filtering the packages affected with additional steps in my release action workflow, and then invoking a NPM script "deploy-artifact" in each affected package. This is working well for a process to upload a versioned artifact to AWS. I am interested to know if others are doing the same.
I will benefit from advice about how others are handling environments. I started down the path of using branches, but that got messy with various workflow files. Now I think I want to try NPM packages for each environment, e.g. "@myOrg/env-dev", "@myOrg/env-qa", "@myOrg/env-prod". The downside of this strategy is that I have more packages to think about, one for each environment. The upside for this approach is that I can use PRs to control the dependencies used by each environment, the dependency versions can be managed like normal code packages, and I can use the same release strategy used for non-environment packages, overloading the local package's NPM script "deploy-artifact" to run infrastructure updates referencing the versioned dependency artifacts.
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
I want to know how others are managing multiple environments with the releases created by Github Actions and the release workflow offered by changesets.
I have successfully integrated the Bot and Action into one organization's development process. It was not obvious how to build and store release artifacts (e.g. lambda packages, docker images). I achieved building and uploading release artifacts by filtering the packages affected with additional steps in my release action workflow, and then invoking a NPM script "deploy-artifact" in each affected package. This is working well for a process to upload a versioned artifact to AWS. I am interested to know if others are doing the same.
I will benefit from advice about how others are handling environments. I started down the path of using branches, but that got messy with various workflow files. Now I think I want to try NPM packages for each environment, e.g. "@myOrg/env-dev", "@myOrg/env-qa", "@myOrg/env-prod". The downside of this strategy is that I have more packages to think about, one for each environment. The upside for this approach is that I can use PRs to control the dependencies used by each environment, the dependency versions can be managed like normal code packages, and I can use the same release strategy used for non-environment packages, overloading the local package's NPM script "deploy-artifact" to run infrastructure updates referencing the versioned dependency artifacts.
Beta Was this translation helpful? Give feedback.
All reactions