Shameless plug: I'm currently working on a service that'll spin up / tear down environments automatically for each branch in your repo. We're focusing on the manual testing use case between designers and front-end engineers, so prod deployment is omitted from our featureset. But if you're looking to spin up ephemeral environments without building something yourself, check us out: <a href="https://featurepeek.com" rel="nofollow">https://featurepeek.com</a>
So, as a dev-ops engineer, I'm trying to decide if I'm onboard with this idea. I still don't see the justification though.<p>The idea of provisioning an environment to test a branch seems like a lot of overhead. Concretely, how long does it take to spin up an environment, install the containers/app, and run tests?<p>I imagine the answer is going to be over an hour.<p>Definitely feels like a lot of overhead, particularly when most branches change ~.1% of an application's code and so theoretically the full-diff is kilobytes worth of data.<p>-<p>The alternative of course is just to have a pre-set number of build-servers (e.g. 5) and then have jenkins dynamically run jobs against them. Seems simpler, I assume faster, and just less risky.
We need this so much.<p>The environment is part of the product. With software, if you can't easily and automatically recreate your builds from source, you have a problem.<p>This ought to apply to cloud environments too.
Wow is this ever overkill.<p>This needs to be coupled with a lot more “how and we we picked this methodology” advise or information.<p>For example, if the goal is to reduce risk then is this the best way to approach that? Are all these components black boxes which cannot be stubbed out? Are there any other end to end or integration tests that can be ran in a canary environment that are way faster which will cover the most obvious use cases?<p>Id really think a few times before adopting this practice.