

Ask HN: Trying to collect data about the state of staging in web dev - ubermuda

I am currently collecting informations about how and why people do staging in the web development industry. Would you be so kind as to answer (and share!) that 2 min survey?<p>http:&#x2F;&#x2F;stage1.io&#x2F;survey?ref=hn0<p>I&#x27;ll be happy to discuss that in the comments too.
======
ollysb
This is one of the areas where heroku does a great job. It's very good at
cloning apps, if you're using their addons(memcache, redis, etc.) it'll take
care of provisioning new instances automatically. We use amazon rds but that's
the only thing we have to setup if we want a new environment. Now that
postgres is available on amazon we'll probably switch to that which will mean
we can even use a cheapo heroku postgres instance for product demos etc.

With regards to setting up a company to do this, I'm not sure. A staging
environment really needs to be as close as possible to production. Perhaps
docker will become enough of a standard that it'll be easy to match production
apps much easier in different clouds...

~~~
ubermuda
When I tell people about an automated staging deployment platform (let's not
talk about a company yet, even if that is indeed the ultimate goal), they
often ask "what does your product do that heroku doesn't?". That answer is
simple, it's in the vision of the product. Heroku is production platform, and
everything is geared toward great performance, ease of setup and scalability.
IMHO, only one of these characteristics is essential to a staging platform:
ease of setup.

I think the real added value of a successful staging platform will come from
staging specific features, like making everything automated, easing feedback
gathering, one-click staging/prod mirroring, etc. Docker and other isolation
or virtualization technologies are most certainly a step in the good
direction, but that's precisely what I'm trying to mesure with that survey and
the discussion around it.

~~~
grey-area
By far the biggest problem with this concept is that the staging environment
must exactly mirror the production environment, as the parent pointed out.

So it's going to come down to being able to reproduce the production in
staging (db, web server, plugins, bandwidth, memory, storage, data and the
exact version of all of these - every bit of state which might affect
production), which would be an awful lot easier if you are also serving the
production side, or perhaps if you have a very limited set of supported
production targets. It's a tricky problem and one that's hard to solve if you
don't control production.

Having set up a few staging environments, here are things Id find
handy/essential, for what it's worth:

Exact duplication of production setup

Easily getting scrubbed production data into staging

Easy replication (probably with version control)

Easy deployment to production

Easy rollback (probably with multiple instances)

Feedback might be nice I guess if you had a sort of comment on this page
system, could easily grow out of control though into a ticket management
nightmare - many managers use email/phone for this and are hard to wean off
it.

NB that if you don't have no.1 on that list, nothing else matters, and people
are not going to want to use a different tool to deploy dev and production.

------
ville
Shameless plug: If you're interested in data about development processes,
please also fill in our IDE and editor survey at
[https://docs.google.com/forms/d/1lgp25sLFCKw5K58mrxb4PmIpZpn...](https://docs.google.com/forms/d/1lgp25sLFCKw5K58mrxb4PmIpZpn0yzAD329EFVB0ZKI/viewform)
(HN discussion:
[https://news.ycombinator.com/item?id=6761225](https://news.ycombinator.com/item?id=6761225)).
We will publish all the results and the analysis afterwards.

------
japhyr
Link: [http://stage1.io/survey?ref=hn0](http://stage1.io/survey?ref=hn0)

------
oelmekki
Answered.

I'm looking forward to see what you want to do with this, handling staging
environment in the age of cloud can be a real pain.

~~~
yogo
I took the survey, which got me thinking about my staging environments then I
concluded that it wasn't that big of a pain. The main thing that came to mind
was db schema synchronization.

~~~
oelmekki
Yes, maybe I should have been more explicit, sorry.

I'm now using dedicated servers, so staging is quite straightforward. But
before that, I was in a company which had two heroku applications tied
together through api, and a dedicated aws for optical processing (also tied
through api).

Having two apps was mainly a memory concern with heroku dynos and the third on
aws was to install custom software, so we had three applications where we
would probably had a single on dedicated machines.

Anyway, the pain in that was we had to replicate the exact same relation
between all staging apps, mirroring production apps (so, two heroku apps and
one on dedicated server).

I can imagine that such app specialization is something we will see more and
more, thus the harder task it may imply in staging env setting.

~~~
ubermuda
The great thing is that emerging (or established actually) technologies and
APIs now permit to modelize complex apps topologies and duplicate them at will
(I'm thinking VMs and containers here), so the pain you describe is just one
automation away ;)

------
preddict
No subversion in the CVS options? I still think it's a great option for dev
teams of 2 or 3 people.

------
christophe971
Survey submitted here, although I mostly use a vanilla remote git repo to
manage my projects.

------
pmzy
I answered too. We use a homemade solution but it's quite a pain to maintain.

