Sync staging with main
The best way to maintain a staging environment is by syncing it with your
mainline git branch - every time a change is made to main
, trigger a deploy to
staging. Whether through direct pushes or successful pull requests, this will
ensure that the staging environment always mirrors the main
branch of your
repo.
The workflows below will first create a new latest
tag of your component in
Architects registry. Then it will trigger architect deploy
to ship that
component and its changes to an existing staging
environment. This environment
is not created by this workflow since it is intended to be persistent, so you’ll
have to create the environment in advance.
Github actions
name: Deploy main
env:
ARCHITECT_EMAIL: ${{ secrets.ARCHITECT_EMAIL }}
ARCHITECT_PASSWORD: ${{ secrets.ARCHITECT_PASSWORD }}
ARCHITECT_ACCOUNT: <account-name>
on:
push:
branches:
- main
jobs:
architect:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v3
- uses: actions/setup-node@v3
with:
node-version: "16"
- uses: crazy-max/ghaction-github-runtime@v2
- name: Tests
run: echo "Run your tests here"
- name: Install Architect CLI
run: npm install -g @architect-io/cli
- name: Login to Architect Cloud
run: architect login
- name: Register and deploy to Staging
run: architect deploy architect.yml --environment staging --auto-approve
Cut releases for production
The last step of your GitOps workflow is to finally get your code into
production! If you want, you’re welcome to use the workflow described previously
to automatically deploy from main
straight to production, but in this workflow
we’ll show how to trigger the deployment on a manual release cut. By triggering
on new releases, we can log a version history of all the code that made its way
to production to make it easier to instrument rollbacks.
The workflows below will first register the component with a tag matching the
name of the new release. Then they will deploy the new component tag to an
environment named production
. Obviously production is intended to be
persistent, so you’ll have to create the environment in advance.
Github actions
name: Deploy release
env:
ARCHITECT_EMAIL: ${{ secrets.ARCHITECT_EMAIL }}
ARCHITECT_PASSWORD: ${{ secrets.ARCHITECT_PASSWORD }}
ARCHITECT_ACCOUNT: <account-name>
on:
release:
types:
- published
branches:
- main
tags:
- v*.*.*
jobs:
architect:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v3
- uses: actions/setup-node@v3
with:
node-version: "16"
- uses: crazy-max/ghaction-github-runtime@v2
- name: Tests
run: echo "Run your tests here"
- name: Install Architect CLI
run: npm install -g @architect-io/cli
- name: Login to Architect Cloud
run: architect login
- name: Register and deploy to Production
run:
architect deploy architect.yml --environment production --auto-approve
Configurable workflows
Architect can automatically generate GitHub workflows to coordinate component
deployments throughout the entire development lifecycle. These deployment types
include deployments to preview environments, deployments based on merging to a
specific branch such as main
, or deployments to production. If your component
is connected to GitHub already, these workflows can be configured on the
component settings page. If your component hasn’t yet been connected to GitHub,
that can be done by selecting the “Connect repo” button, then following the
prompts. The button is at the top of a component page like in the following
image.
The following workflows expect that GitHub secrets ARCHITECT_EMAIL and
ARCHITECT_PASSWORD exist in your component’s connected repo. The password is
an Architect access token and can be generated on your access tokens page.
Preview environments
The following workflow deploys a component preview environment: a temporary
deployment of a specific component that is spun up when a pull request is
opened. The deployment will occur on the cluster and the account name specified
in the GitHub workflow file.
A preview environment will be deployed during the following events:
- A pull request is opened
- A pull request has new code pushed to the repo
- A pull is re-opened
The deployment will be torn down after the pull request is closed.
Below is an example of a preview environment workflow that Architect will
generate for a component.
name: Architect Preview Deployment
on:
pull_request:
types:
- opened
- synchronize
- reopened
- closed
env:
ARCHITECT_GENERATED: true
ARCHITECT_PREVIEW: true
PREVIEW_PREFIX: preview-
PREVIEW_TAG: preview-${{ github.event.number }}
PREVIEW_MAINLINE_BRANCH: main
COMPONENT_FILE_PATH: architect.yml
ARCHITECT_ACCOUNT: <architect-account>
CLUSTER_NAME: <architect-cluster>
COMPONENT_NAME: <architect-component>
ENVIRONMENT_TTL:
jobs:
architect_remove_preview:
if: github.event.action == 'closed'
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v3
- uses: actions/setup-node@v3
with:
node-version: "16"
- name: Install Architect CLI
run: npm install -g @architect-io/cli
- name: Login to Architect Cloud
run:
architect login -e ${{ secrets.ARCHITECT_EMAIL }} -p ${{
secrets.ARCHITECT_PASSWORD }}
- name: Remove preview environment
run:
architect environment:destroy ${{ env.PREVIEW_TAG }} --auto-approve -f
|| exit 0
architect_create_preview:
if: github.event.action != 'closed'
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v3
- uses: actions/setup-node@v3
with:
node-version: "16"
- uses: crazy-max/ghaction-github-runtime@v2
- name: Install Architect CLI
run: npm install -g @architect-io/cli
- name: Login to Architect Cloud
run:
architect login -e ${{ secrets.ARCHITECT_EMAIL }} -p ${{
secrets.ARCHITECT_PASSWORD }}
- name: Create env if not exists
run:
architect environment:create ${{ env.PREVIEW_TAG }} --cluster ${{
env.CLUSTER_NAME }} ${{ env.ENVIRONMENT_TTL }}
- name: Register and deploy component
run:
architect deploy --auto-approve -e ${{ env.PREVIEW_TAG }} ${{
env.COMPONENT_FILE_PATH }}
Branch deployments
Branch deployments will deploy a component when code is pushed to a specific
branch. A branch deployment could be used to set up user acceptance testing
environments that will create deployments when new features are pushed to main
or another specific branch. Like preview environments, the deployment will be
created in the specific environment and account specified in the file.
The example below is configured to deploy a component to the Architect
environment <environment-name>
of the account <account-name>
when code is
pushed to the main
branch on GitHub.
name: Architect main Branch Deployment
on:
push:
branches:
- main
env:
ARCHITECT_GENERATED: true
ARCHITECT_BRANCH: true
COMPONENT_FILE_PATH: architect.yml
ARCHITECT_ACCOUNT: <architect-account>
COMPONENT_NAME: <architect-component>
ENVIRONMENT_NAME: <architect-environment>
BRANCH_NAME: main
jobs:
architect_create_branch_deployments:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v3
with:
ref: ${{ env.BRANCH_NAME }}
- uses: actions/setup-node@v3
with:
node-version: "16"
- uses: crazy-max/ghaction-github-runtime@v2
- name: Install Architect CLI
run: npm install -g @architect-io/cli
- name: Login to Architect Cloud
run:
architect login -e ${{ secrets.ARCHITECT_EMAIL }} -p ${{
secrets.ARCHITECT_PASSWORD }}
- name: Register component w/ Architect
run: architect register ${{ env.COMPONENT_FILE_PATH }} -t latest
- name: Deploy component
run:
architect deploy --auto-approve -e ${{ env.ENVIRONMENT_NAME }} ${{
env.COMPONENT_NAME }}:latest
Release deployments
Release deployments are set up to deploy a component when a release is published
in the connected GitHub repo. This can be used to support production
environments by creating new deployments when releases occur.
The below workflow shows an example that will deploy the component to the
environment <environment-name>
of the account <account-name>
when a release
is published in the connected GitHub repo.
name: Architect Production Deployment
on:
release:
types:
- published
env:
ARCHITECT_GENERATED: true
ARCHITECT_PRODUCTION: true
COMPONENT_FILE_PATH: architect.yml
ARCHITECT_ACCOUNT: <architect-account>
COMPONENT_NAME: <architect-component>
ENVIRONMENT_NAME: <architect-environment>
jobs:
architect_create_release:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v3
- uses: actions/setup-node@v3
with:
node-version: '16'
- uses: crazy-max/ghaction-github-runtime@v2
- name: Install Architect CLI
run: npm install -g @architect-io/cli
- name: Login to Architect Cloud
run: architect login -e ${{ secrets.ARCHITECT_EMAIL }} -p ${{ secrets.ARCHITECT_PASSWORD }}
- name: Register component w/ Architect
run: architect register ${{ env.COMPONENT_FILE_PATH }} -t latest
- name: Deploy component
run: architect deploy --auto-approve -e ${{ env.ENVIRONMENT_NAME }} ${{ env.COMPONENT_NAME }}:latest
PREV