Environments are deployment targets

CI variables can be scoped to environments

Environments are auto-created by the first job using them

Your demo environment has hidden services

WebDAV endpoints emulate deployment targets

Hands-On (1/2)

  1. Retrieve passwords for dev and live environments from the info page
  2. Create unprotected CI variable PASS twice with scope dev and live
  3. Create unprotected CI variable SEAT_INDEX with your seat number
  4. Add new stage and job called deploy
  5. Upload to WebDAV server dev using curl
  6. Download from https://dev.seatN.inmylab.de/hello
  7. Check environments

See new .gitlab-ci.yml:

git checkout origin/160_gitlab_ci/100_environments/demo1 -- '*'

Pro tip

Branches can be used to represent target environments:

Hands-On (2/2)

  1. Create branch called dev
  2. Use environment ${CI_COMMIT_REF_NAME}
  3. Commit and check pipeline
  4. Create branch live from dev
  5. Download from https://dev.seatN.inmylab.de/hello and live equivalent

See new .gitlab-ci.yml:

git checkout origin/160_gitlab_ci/100_environments/demo2 -- '*'

Pro tip: Disposable environments

Additonal use of environments: disposable review apps

Environments can have a stop action for disposal

Environments can have an expiration time

  when: manual
    name: quick-help
    url: https://quick-help.vscode.inmylab.de
    on_stop: vscode-cleanup
    auto_stop_in: 1h
  script: echo DEPLOY

  - vscode
    name: quick-help
    url: https://quick-help.vscode.inmylab.de
    action: stop
  when: manual
  script: echo DESTROY