profile with env vars

You can use UPcmd to chain the command output as input and choose a task to handle the data processing

concept

So far, we can use an instanceid as context id to select what set of configuration we want to use, nomally they are categorized by global configuration, environment group configuration and individual context instance, for example as below:

global\_
        |_nonprod
            |_dev
            |_staging
        |_prod
            |_prod

You could use [ up ngo mytask -i dev ] to do deployment work aginst dev environment

However these configuration are more like server (backend) configuration. Most of time, we will have some other configurations, they are related to pipeline user input, for example:

  • username
  • password(secured)
  • flags for build/deployment/workflow to behave differently, eg,
    • create db everytime or skip
    • a resource id (ec2-instanceid/iam-profile-id/database name etc) as data injection for the workflow
  • temporary config entry for manual test

All these settings are more like a user execution profile rather static and stable server environment configuration, they are the environment variables input from users

In this case we could classify them all together into an execution profile, for example

dev(instanceid):
|_ ENV var1
|_ ENV var2
|_ ENV var3

global\_
        |_nonprod
            |_dev
                 \_dev1_test
                 \_dev2_test:
                 \_dev1_use_memcache:
                 \_dev2_no_db_recreat
            |_staging
        |_prod
            |_prod

By using such a execution profile, the CI/CD tools does not need to handle the multiple environment variable entries and secure variable entries, all these could be handled by UPcmd. To trigger the pipeline, a code push is all needed.

This turns the audit to a precise git commit history so it is tracable to understand whose code has actually cause the problem

Best practice

  1. Turn every pipeline settings, eg multiple environment variables to so called evar (evironment var) pair under eprofiles/evars/[key,value]
  2. All the other global/group vars, instance vars, runtime global vars are still kept the same ways as they are
  3. Normally, for your existing CLI CI/CD build, you would have already got the logic to map the environment vars to your internal programming vars, these will be kept the same as they are
  4. The env vars in eprofiles are already takeing effect, they are just like the env vars you setup in your pipeline GUI to take baisc parameters to instruct how the build/deploy will behave
  • Conventional CI/CD pipeline
env vars -> pipeline tool via GUI settings -> CLI workflow
  • UPcmd pipeline UPcmd ==match profile name==>> eprofile/evars => UPcmd managed workflow

Showcase

Please note the execution profile extend dev instance, see the differences of the final var merged

up ngo task -d ./tests/functests -t c0153 -p dev1_use_memcache --configdir=./tests/functests

Relavant

environment variables

references