3 ms·
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. The idea of provisioning an environm
by alexandercrohde 8y ago
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.
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?
I imagine the answer is going to be over an hour.
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.
-
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.
- chupasaurus 8y ago> The idea of provisioning an environment to test a branch seems like a lot of overhead. The idea of running integration tests on a non-complete environment seems like a lot of fun at the release. > Concretely, how long does it take to spin up an environment, install the containers/app, and run tests? I work currently at the community-sized online bank, total time of our pipeline to spin up a new "bank" is 22 minutes, running multiple of these envs on 4 HDDs in RAID 10. We'd move the whole thing on flash array in 2 weeks and my estimation is that this metric will go down to 7-8 minutes. > 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. You have to run these builds somewhere, if changes would run on a single staging env, it would be down most of the time. If it would be a handful of stagings, it might be still not enough because either you wouldn't have enough of them and it'll ended up to the single env situation multiplied, or you would burn cash for idle servers.