I would like prepare my old project to work wiith separate environments, e.g. for Development, Staging and Productions. I would like hear about your experience or listen your suggestion.

Project is hosted on Github and CI/CD will be running by Github Actions.

I would like prepare 3 stages:

  • development: used by developers on own local machines based on docker, with flat structure, with debug = true, with API keys for sandboxes, database migrations, database seeds and unit, integration and e2e tests;
  • staging: used for showing progress of project for clients on public server, based on docker, with flat structure, with debug = false, with API keys for sandboxes, database seeds and unit, integration and e2e tests;
  • production: as target project, on public server, optionaly based on docker, with release directories and symlink to the newest, with the possiblity of rollback, with debug = false, with target API keys and database migrations.

I prepare sepearate workflows on Github: staging.yaml and production.yaml.

Of course, it’s not necessary for works on development stage.
Also I use Deployer for running commands, but it’s not that relevant for this thread.

staging.yaml:

step: build
- build docker environment (or pull and push)
- run docker
- build app (e.g. install vendors)
- unit tests
- integration tests
- export build app as artifacts
step: prepare server (e.g. droplet on DigitalOcean)
- unzpi artifacts
- build docker enviroment with e.g. database
- run docker
- install vendors
- database seeds
step: tests
- run e2e tests
step: publish
- set subdomain (or domain) to docker environment

production.yaml:

step: build
- build docker environment (or pull and push)
- run docker
- build app
- export build app as artifacts
step: connect to existing server (e.g. droplet on DigitalOcean)
- make new dir in releases/ directory 
- unzpi artifacts to newest directory in releases/ directory
- run docker (or no)
- database migrations
- symlink direcotry (used as DOCUMENT_ROOT) do newest directory in releases/ directory
step: publish
- just set success message
  1. Firstly, it’s descrbed stages like these will be good?
  2. It’s good to run production and staging stages as separate or rather should be run as pipeline, production stage only after staging stage (as dependent)?
  3. In Github Action can’t sharing artifacts between jobs, so steps for building docker (pulling/pushing), running docker and building app are duplicated. This increases the duration of the CI/CD process, it’s okay?
  4. Maybe better will be build app once and saving on docker image, then can be shared between other jobs or even stages?
Submit an answer

You can type !ref in this text area to quickly search our full set of tutorials, documentation & marketplace offerings and insert the link!