#release-engineering (2022-09)
All things CI/CD. Specific emphasis on Codefresh and CodeBuild with CodePipeline.
CI/CD Discussions
Archive: https://archive.sweetops.com/release-engineering/
2022-09-24
Hello everyone, I am building a CI/CD pipeline for a product and I am confused with a few things.
I have so far worked in a system where I used to do “code promotion” for environment progression ie each branch pointed towards a certain env and PRs between the branches but very recently I read about “artifact promotion” and I feel like it is sensible thing to do and want to give it a try.
Now for my microservices, I am able to manage it by keeping Docker image for each env, free from any env specific variables and supplying env variables to my pod directly. It all works. But for my frontend, I am hosting it using S3 & CloudFront and I am using Next JS f/w and the way env variables work in Next JS is that we need to supply them at *build* time and they get embedded in the export/dist.
How do I do “artifact promotion” in such cases, specially when the env variables are different for each environment.
PS: I know this question is very specific to my use case. Apologies if I am asking it at a wrong place!
I think if you need a customised build for each environment, artifact promotion is not suitable. Or redefine “artifact” to mean “a zip of the source code” and deployment to mean “compile the app”.
I’d also ask the NextJS community if there is some reasonable way to inject these variables at run time.
1
I’m not very familiar with frontend tech, but does this help you? https://burnedikt.com/spa-runtime-configuration-for-multiple-environments-using-webpack/ We used to do something similar in a project I worked on; there, we loaded the environment-specific config straight from the index.html file. So then you’d just copy a different environment config file at deploy-time, rather than build-time.