Design needed: CI/CD should apply its own .env configurations


(These are rough notes—Do not start work on this ticket before Team ILL turns this into a complete ticket with direction and acceptance criteria.)

Design/specifications are needed around how the CI/CD system should get the proper .env configurations for different environments.

Using the default .env file is acceptable for short-lived environments, but not for deployed and persisted environments. When Jenkins is running jobs for testing, erd generation, sonar, etc, it's ok to use the default .env file, which is publicly accessible in github. Because the DB containers started in CI with the default .env file won't have any real data stored in them and they will be very short-lived, usually no more than 10 mins.

For environments that persist, like Demo and UAT sites, the .env files used to start them need to be protected against public access. Right now, they are in a directory in the Jenkins master machine, and a private git repo could serve the same purpose.

This may include:

  • stop using the generic .env file each time the CI builds

  • set up a private repository to store those environment-specific .env files:

  • create environment-specific .env files (like uat.env, demo.env, etc) in that private repo

  • have CI/CD system use those environment-specific .env files from that private repo (requires wrapping those .env in the proper ZIP file with the other docker credentials that are uploaded to Jenkins' security credentials)

  • have server enforce HTTPS (there is a ticket for SSL)

  • demo data (TBD, and has other tickets)

  • seed data (TBD, and has other tickets)





Brandon Bowersox-Johnson