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?

http://stage1.io/survey?ref=hn0

I'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 → ollysb]

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 → ubermuda]

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... (HN discussion: 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

[_pctq]

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 → _pctq]

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.

[_pctq → yogo]

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 → _pctq]

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 ;)

[ubermuda → yogo]

Can you be more explicit? Are you talking about synchronizing the db schema when updating a staging env, or say, sync the schema accross multiple env each hosting a different version of the app?

[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.