See also: http://hypernode.uservoice.com/forums/242854-hypernode/suggestions/5885976-cost-effective-solution-for-staging-test-servers

Ik heb de voorkeur voor een subdomein oplossing..
O doe je maar lekker lokaal.

A zou mijn inziens op de live server kunnen als subdomein. Redis ondersteund meerdere databases, in MySQL is het eenvoudig te doen, dan heb je het snelst een acceptatie in de lucht met dezelfde specs.

Mocht je behoefte hebben aan een T, zou een aparte hypernode een goede oplossing zijn.
Er zou een een test-server kunnen zijn welke je voor meerdere projecten gebruikt.
Om eenvoudig op 1 server met subdomeinen te kunnen testen. Bij mij werkt het al voor ontwikkeling.

Lokaal ontwikkel ik met 1 configuratie in Nginx.
*.*.*.local

Met een regel in Nginx voor klant.project.store.local
Die derde kan overigens vergeten worden voor de default.
Welke vertaald naar home/test/klant/project/httpdocs/index.php oid

Ik vind het altijd wel prettig om zaken buiten de docroot te kunnen zetten, vandaar de httpdocs.

Ha Anoniempje :)

Voor O en T hebben we inmiddels een Vagrant image beschikbaar waar je op kunt ontwikkelen:

https://github.com/ByteInternet/hypernode-vagrant/

Voor A zijn verschillende oplossingen. Wat zou je prefereren?

1. Een staging subdomein op je Hypernode waar je e.e.a. kunt uploaden, maar waar je dus resources pikt van je live site. Resources zijn vooral: CPU en PHP worker slots. Ook heb je dan geen aparte Redis en geen aparte MySQL. Deze oplossing kost eigenlijk niets meer dan dat je al betaalt.

2. Een aparte node, die identiek is aan je live Hypernode waar je ontwikkelt. Alle resources zijn gescheiden en er is ook een aparte Hypernode URL beschikbaar. Deze oplossing kost eigenlijk gewoon hetzelfde als een Hypernode en is al beschikbaar als je een tweede node aanvraagt. Technisch gezien is het de beste oplossing, want ceteris paribus.

3. Een node die je on-demand opstart en identiek is aan een Hypernode, maar tijdelijk. Betaling is dan ook on-demand. Technisch voor ons ingewikkeld om te maken, voor de billing is een nachtmerrie :) Wat zou je een eerlijke prijs vinden voor zo'n feature?

Groetjes,

Allard
Hypernode

Hi all who voted. At the moment, we have an up-to-date Vagrant image available for your pleasure. See https://github.com/ByteInternet/hypernode-vagrant

This covers the Dev/Test part of DTAP ;)

For acceptance testing: a clone on the same server is free but had the disadvantage that it takes away resources from your production site. A cleaner solution seems to have an identical Hypernode booted and running for the duration of your demo/acceptance procedure.

Given the latter option, what would you (or your client ;)) be willing to pay for such a feature? For example, x% extra per month to have an identical staging env running?

Maybe an idea to put up hypernodes voor 1 week or a couple of days ?

Create the changes on the local vagrant server, and if they are ready for release put up a clone hypernode and voila the client can test.

After the test the hypernode can be 'down'

Sorry, but I can't let customers accept releases for a site on vagrant images. I think we have one client that would be able to do so without coaching.
Maybe a hypernode instance should include an actual staging and be able to switch the ~/public and ~/staging directories as part of deployment.
The vagrant image is welcomed for testing and development of course.

Yes! I would be happy with a Vagrant image! Also, please integrate it with docker. This makes everything faster. Because the boot2docker image boots in 5s.

Here is a link: http://docs.vagrantup.com/v2/docker/basics.html

Would you be happy with a Vagrant image to reach this goal? So you could use "vagrant up" and voila, have an almost identical local server.