​
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.

ARCHITECT_PASSWORD must be a personal access token.

​
Github actions

name: Deploy main

env:
  ARCHITECT_EMAIL: ${{ secrets.ARCHITECT_EMAIL }} # pass secrets into a job from Github > Settings > Secrets
  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 # Exports internal envs for Github Actions. Required for register caching to work.
      - 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 # credentials loaded automatically from envs ARCHITECT_EMAIL/ARCHITECT_PASSWORD
      - 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.

ARCHITECT_PASSWORD must be a personal access token.

​
Github actions

name: Deploy release

env:
  ARCHITECT_EMAIL: ${{ secrets.ARCHITECT_EMAIL }} # pass secrets into a job from Github > Settings > Secrets
  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 # Exports internal envs for Github Actions. Required for register caching to work.
      - 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 # credentials loaded automatically from envs ARCHITECT_EMAIL/ARCHITECT_PASSWORD
      - 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 # Exports internal envs for Github Actions. Required for register caching to work.
      - 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 # Exports internal envs for Github Actions. Required for register caching to work.
      - 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 # Exports internal envs for Github Actions. Required for register caching to work.
      - 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
ClustersSecrets