Join 1M+ other developers and:
- Get help and share knowledge in Q&A
- Subscribe to topics of interest
- Get courses & tools that help you grow as a developer or small business owner
Idea of Development, Staging and Production environments and steps with Github Actions
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.
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
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
- Firstly, it’s descrbed stages like these will be good?
- 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)?
- 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?
- Maybe better will be build app once and saving on docker image, then can be shared between other jobs or even stages?