3 ms·

Dependable and repeatable environments are essential. At my company the issue is that dev/qa/stage/prod are all not ===. We end up with two options to fix some

by kreek 16y ago

Dependable and repeatable environments are essential. At my company the issue is that dev/qa/stage/prod are all not ===. We end up with two options to fix something. Make a fix and send it through the deployment process (over and over again). Or sit in a sysadmins lap and try to fix it. Both options are extremely frustrating, for both parties, and generate a lot of animosity.

pedoh 16y ago
It's not easy, is it? Imagine being able to spool up a new environment (on one server as opposed to, say, 5 in production) and feed it a copy of production data, run tests, and then tear it down. And imagine knowing that this environment was identical to production in every way except for minor configuration changes to get it to run on one box. And when you're done with it? Throw it away. That's really powerful. A new employee comes on board? Here, here's your environment. Mess with it as much as you want, we can just rebuild it if you totally hose it. All QA except for performance testing, which would need to be done on real hardware anyway, could be done in these environments.
- danudey 16y ago
  I worked at a company where we had a similar system set up. We had automated database snapshots of production taken every two hours, and stored locally and in our account at Rackspace's Cloud Files. Eventually, I got fed up with people asking me to update staging with a copy of the production database, so I wrote a simple Python script and stuck it in the repository. As long as you weren't running in a production environment, it would give you a fresh copy of the database in a matter of minutes. We were (slowly) working towards a system where the entire app (gems and all) was self-contained, and we had a list of all the system packages that needed installation; once we reached that point, setting up a new server would have been a five-minute job - a git pull, a package update/install, and a database pull. Sadly, we never did get around to finishing it (actual work took priority), but it would have been nice to have.

by kreek 16y ago

pedoh 16y ago

It's not easy, is it? Imagine being able to spool up a new environment (on one server as opposed to, say, 5 in production) and feed it a copy of production data, run tests, and then tear it down. And imagine knowing that this environment was identical to production in every way except for minor configuration changes to get it to run on one box. And when you're done with it? Throw it away. That's really powerful. A new employee comes on board? Here, here's your environment. Mess with it as much as you want, we can just rebuild it if you totally hose it. All QA except for performance testing, which would need to be done on real hardware anyway, could be done in these environments.

danudey 16y ago
I worked at a company where we had a similar system set up. We had automated database snapshots of production taken every two hours, and stored locally and in our account at Rackspace's Cloud Files. Eventually, I got fed up with people asking me to update staging with a copy of the production database, so I wrote a simple Python script and stuck it in the repository. As long as you weren't running in a production environment, it would give you a fresh copy of the database in a matter of minutes. We were (slowly) working towards a system where the entire app (gems and all) was self-contained, and we had a list of all the system packages that needed installation; once we reached that point, setting up a new server would have been a five-minute job - a git pull, a package update/install, and a database pull. Sadly, we never did get around to finishing it (actual work took priority), but it would have been nice to have.