search

kHRISl33t / runtime-env-cra

Runtime environment handler for create-react-apps
MIT License
49 stars 23 forks source link

Usage on S3 or other static file server? #9

Open nlien opened 3 years ago

nlien commented 3 years ago

I was hoping to use this tool to generate a runtime config for my SPA in a static file server environment, like S3.

I might have misunderstood, but AFAICS, there's nothing standing in the way of running this command before uploading the assets to eg. an S3 bucket

Take this pseudo code, happening on a CI/CD environment (ie. AWS CodePipeline, Travis etc.):

Build phase

Deploy phase

IMO, this workflow could be beneficial if I want to build once, deploy anywhere. My CI/CD environment could for instance build ("build phase") every commit on my main branch. Later I could manually deploy any given build to any given environment using the "deploy phase"

The downside/cons, the way I see it, is that we are modifying the artifact (contents of the dist directory) prior to deploying it. But as long as the script only creates the runtime-env.js file by reading environment variables from the system, I see no harm in it.

What are your thoughts on this? See any potential pitfalls or challenges?

kHRISl33t commented 3 years ago

Theoretically, you are right @nlien! At the moment I can't see any pitfalls with the approach.

If you have a Build phase for every merge/commit on your main branch and the Deploy phase is manual.

You want to define multiple Deploy phases for dev, staging, production where you set your environment variables inside the CI/CD right?

If so, it's a cool approach I didn't think of :) I don't have the time at the moment to try it out, but I will next week!

You can check the code for the .js file generation, it really doesn't do anything else besides the generation.

kHRISl33t commented 3 years ago

I do not have access to any AWS CodePipelines at the moment, but I can prepare a GitLab CI example for later use-cases if that's fine for you.

nlien commented 3 years ago

Thanks for your feedback!

Yes, my thought was to have multiple "deploy phases", where each phase represents an environment.

If you have the time and effort to prepare a use-case in GitLab CI, that would be much appreciated! I'm going to test this is out in AWS Code* myself during this week or the next, hopefully.

kHRISl33t commented 3 years ago

Cool!

Hopefully later on this week I can prepare an example for GitLab CI.

seanblonien commented 3 years ago

@nlien You very nearly have exactly the same flow I have, but I think if you just move the runtim-env generate part to the build, and it'd makes more sense.

If you are following a build-once approach for your CI/CD pipeline where you build your release artifacts once for all environments and then promote them up, then all you really have to do is add a step in the build process to duplicate the artifact and run runtime-env-cra for said artifact for every environment.

For me it's this simple:

I use a node script to do this which is why you see that template string literal syntax. I put that script usage in an package.json script to make it a bit cleaner, and I can control what environments are passed to the node script, always corresponding to all of the .env files in the project (just realized I could just scan the project files and the script do that for me). You could probably do this using command line utils alone, but I wouldn't recommend it.

If you have the multiple deploy phases like Kristof suggested, you can control when each artifact is released/deployed however you see fit without worrying about generating configs. The builds are completely static once built.

Problems with this approach: you have to rebuild every time you want to change environment variables for any environment, but that's pretty clearly the tradeoff we're making here, and in my opinion fine because this embodies infrastructure as code practices.