feat: make it follow the standard "release branch" workflow

.github/workflows/release.yml → .github/workflows/merge_dev_to_stage.yml

@@ -1,15 +1,17 @@
-name: Release
+name: Merge dev to stage
 on:
   workflow_dispatch:
   schedule:
     - cron: '15 14 * * *'
 jobs:
-  test:
-    name: Test
-    runs-on: ubuntu-20.04
+  merge:
+    name: Merge
+    runs-on: ubuntu-latest
     steps:
       - name: Checkout
         uses: actions/checkout@v3
+        with:
+          ref: 'dev'
 
       - name: Merge dev to stage
         uses: devmasx/[email protected]

.github/workflows/test.yml

@@ -58,6 +58,14 @@ jobs:
           ${{ github.ref  == 'refs/heads/dev' && vars.NETLIFY_STORYBOOK_ID != ''
           }}
 
+      - name: Merge release to prod (silverback-template only)
+        uses: devmasx/[email protected]
+        if: ${{ github.repository == 'AmazeeLabs/silverback-template' && github.ref  == 'refs/heads/release'}}
+        with:
+          type: now
+          target_branch: prod
+          github_token: ${{ github.token }}
+
   docker_build:
     name: Docker Build
     if: startsWith(github.ref_name, 'test-all/')

.lagoon.yml

@@ -21,7 +21,7 @@ tasks:
         command: drush scr scripts/translations-import.php
         service: cli
 environments:
-  dev:
+  prod:
     routes:
       - nginx:
           - example.cms.amazeelabs.dev
@@ -32,3 +32,25 @@ environments:
         schedule: '*/15 * * * *'
         command: drush cron
         service: cli
+  stage:
+    routes:
+      - nginx:
+          - stage-example.cms.amazeelabs.dev
+      - build:
+          - stage-example.build.amazeelabs.dev
+    cronjobs:
+      - name: drush cron
+        schedule: '*/15 * * * *'
+        command: drush cron
+        service: cli
+  dev:
+    routes:
+      - nginx:
+          - dev-example.cms.amazeelabs.dev
+      - build:
+          - dev-example.build.amazeelabs.dev
+    cronjobs:
+      - name: drush cron
+        schedule: '*/15 * * * *'
+        command: drush cron
+        service: cli

INIT.md

@@ -37,7 +37,8 @@ Adjust project machine name in the repo.
 ```ts
 await prompt('PROJECT_NAME_MACHINE', {
   type: 'text',
-  message: 'Project name for machines:',
+  message:
+    'Project name for machines (usually a lowercase version of Jira project code):',
   validate: (name) =>
     !/^[a-z][a-z\d_]*$/.test(name)
       ? 'Must start with a lowercase letter and contain lowercase letters, numbers and underscores only.'
@@ -60,6 +61,18 @@ replace(
   '@amazeelabs/silverback-template',
   process.env.PROJECT_NAME_MACHINE,
 );
+// Template's prod domain is special.
+replace(
+  '.lagoon.yml',
+  '- example.',
+  '- prod-' + process.env.PROJECT_NAME_MACHINE + '.',
+);
+// The rest of domains are standard.
+replace(
+  '.lagoon.yml',
+  '-example.',
+  '-' + process.env.PROJECT_NAME_MACHINE + '.',
+);
 ```
 
 Update the auth key for Gatsby user.

README.md

@@ -20,16 +20,27 @@
 - [Create a new Netlify project](https://amazeelabs.atlassian.net/wiki/spaces/ALU/pages/368017428/Create+a+new+Netlify+project)
 - Check the [Environment overrides](#environment-overrides) section below
 
-## Release and deployment
-
-Development happens in pull requests against the `dev` branch. There is a github
-"Release" workflow that will merge the current state of `dev` into the `stage`.
-This workflow can be triggered from the github UI and will run automatically
-once a day.
-
-The "Deploy" workflow has to be triggered manually from the github UI, and will
-merge the current state of `stage` into `prod` and therefore trigger a
-production deployment.
+## Branches and environments
+
+| Branch     | Connected environment | Purpose                                                                                      |
+| ---------- | --------------------- | -------------------------------------------------------------------------------------------- |
+| `release`  | (none)                | Contains everything that is approved for PROD deployment                                     |
+| `prod`     | PROD                  | The production environment                                                                   |
+| `dev`      | DEV                   | Sandbox/playground, no client data, anyone can merge anything                                |
+| `stage`    | STAGE                 | Second sandbox with client data and automated merge from `dev` to `stage`, regular data sync |
+| `lagoon-*` | (same as branch name) | Can be created for big, long-term feature developments                                       |
+
+## Development workflow
+
+- Create a new branch from `release` and commit your work in
+- Create a PR against `release`
+- Merge your branch to `dev` for testing
+- Testing feedback is committed to the branch and merged back to `dev` for
+  retesting
+- When the PR is approved and Jira ticket gets to the Deploy state, the branch
+  is merged to `release`
+  - Please note, this does not trigger an actual PROD deployment
+- PROD deployment can be done by merging `release` branch into `prod`
 
 ## Installation
 
@@ -226,21 +237,6 @@ when:
 These Cloudinary approximations are not real images and will fail integration
 tests. Therefore they are not used in regular development and testing scenarios.
 
-## Lagoon environments
-
-In a standard project we use three fixed Lagoon environments: `dev`, `stage` and
-`prod`.
-
-- `dev`: Purely for development and integration testing. Content stored here is
-  not guaranteed to be kept.
-- `stage`: Used for user acceptance testing. Content is regularly synced from
-  `prod`.
-- `prod`: The production environment. Do not touch.
-
-Lagoon should also be configured to create automatic environments for feature
-branches that are prefixed with `lagoon/`. Those will be filled with test
-content.
-
 ## "Strangling" legacy systems
 
 The template includes a Netlify Edge Function