Staging (site development) - 2019: verschil tussen versies

Uit De Vliegende Brigade
Naar navigatie springen Naar zoeken springen
Regel 44: Regel 44:
 
! Naam
 
! Naam
 
! Omgeving
 
! Omgeving
 +
! URL
 
! Bash-alias
 
! Bash-alias
 
! Beschrijving
 
! Beschrijving
Regel 50: Regel 51:
 
| s0
 
| s0
 
| Legacy-omgeving (ik zoek nog een goede naam)
 
| Legacy-omgeving (ik zoek nog een goede naam)
| Laptop: <code>s0</code> + <code>naam</code> + <code>.dvb</code>. Bv. <code>s0.example.dvb</code>
+
| Laptop
| s0.hoofddomeinnaam of s0.
+
| <code>s0</code> + <code>naam</code> + <code>.dvb</code>. Bv. <code>s0.example.dvb</code>
 +
| <code>s0.naam</code>
 
| Dit is de 'oude' c.q. 'huidige' site. Dit is in situaties dat ik een nieuwe site bouw, ter vervanging van een bestaande site. Vaak instantiëer ik zo'n site om dingen te kunnen overnemen
 
| Dit is de 'oude' c.q. 'huidige' site. Dit is in situaties dat ik een nieuwe site bouw, ter vervanging van een bestaande site. Vaak instantiëer ik zo'n site om dingen te kunnen overnemen
 
|
 
|
Regel 57: Regel 59:
 
| s1
 
| s1
 
| Ontwikkelomgeving
 
| Ontwikkelomgeving
| Laptop: <code>s1</code> + <code>naam</code> + <code>.dvb</code>. Bv. <code>s1.example.dvb</code>
+
| Laptop
 +
| <code>s1</code> + <code>naam</code> + <code>.dvb</code>. Bv. <code>s1.example.dvb</code>
 +
| <code>s1.naam</code>
 
| ''Development'' of ''development environment''. Dit is waar ik dingen test. Deze omgeving richt ik vaak opnieuw in, omdat-ie vaak een zooitje wordt door allerlei tests. Doorgaans wordt wat ik hier ontwikkel, niet doorgeschoven naar de integratie-omgeving: Als ik iets heb ingericht op de ontwikkelomgeving, maak ik het daarna meestal opnieuw binnen de integratie-omgeving.
 
| ''Development'' of ''development environment''. Dit is waar ik dingen test. Deze omgeving richt ik vaak opnieuw in, omdat-ie vaak een zooitje wordt door allerlei tests. Doorgaans wordt wat ik hier ontwikkel, niet doorgeschoven naar de integratie-omgeving: Als ik iets heb ingericht op de ontwikkelomgeving, maak ik het daarna meestal opnieuw binnen de integratie-omgeving.
 
|-
 
|-
 
| s2
 
| s2
 
| Integratie-omgeving
 
| Integratie-omgeving
| Laptop: <code>s2</code> + <code>naam</code> + <code>.dvb</code>. Bv. <code>s2.example.dvb</code>
+
| Laptop
 +
| <code>s2</code> + <code>naam</code> + <code>.dvb</code>. Bv. <code>s2.example.dvb</code>
 +
| <code>s2.naam</code>
 
| De site binnen de ''integratie-omgeving'' is bedoeld om doorgeschoven te worden naar de ''testomgeving'' en ''productie-omgeving''. Daarom ga ik zorgvulding om met wat er binnen deze omgeving staat. Het is niet bedoeld voor uitprobeersels of tests
 
| De site binnen de ''integratie-omgeving'' is bedoeld om doorgeschoven te worden naar de ''testomgeving'' en ''productie-omgeving''. Daarom ga ik zorgvulding om met wat er binnen deze omgeving staat. Het is niet bedoeld voor uitprobeersels of tests
 
|-
 
|-
 
| s3
 
| s3
| Testomgeving
+
| Externe testomgeving
| Webserver, typisch op een subdomein onder de productie-omgeving. Bv. <code>s3.example.com</code>. Ik gebruik liever niet namen zoals <code>test.example.com</code> of <code>nieuw.example.com</code>, omdat die te hack-gevoelig zijn (je kunt ze namelijk gemakkelijk raden) en niet-professioneel.  
+
| Webserver - Subdomein
 +
| Subdomein onder de productie-omgeving. Bv. <code>s3.example.com</code>. Ik gebruik liever niet namen zoals <code>test.example.com</code> of <code>nieuw.example.com</code>, omdat die te hack-gevoelig zijn (je kunt ze namelijk gemakkelijk raden) en niet-professioneel.  
  
 
Op het moment dat ik nog geen productie-versie van de betreffende site host, dan host ik dit onder <code>devliegendebrigade.nl</code>. Bv. <code>s3.example.devliegendebrigade.nl</code> of <code>s3.projectnaam.devliegendebrigade.nl</code>. Het lijkt overkill om <code>s3</code> toe te voegen, maar ik denk dat dat juist intuïtief is. Zo snel ik de hosting van de betreffende domeinnaam overneem, migreer ik deze situatie naar de eerste variant (dus met subdomeinen)
 
Op het moment dat ik nog geen productie-versie van de betreffende site host, dan host ik dit onder <code>devliegendebrigade.nl</code>. Bv. <code>s3.example.devliegendebrigade.nl</code> of <code>s3.projectnaam.devliegendebrigade.nl</code>. Het lijkt overkill om <code>s3</code> toe te voegen, maar ik denk dat dat juist intuïtief is. Zo snel ik de hosting van de betreffende domeinnaam overneem, migreer ik deze situatie naar de eerste variant (dus met subdomeinen)
 +
| <code>s3.naam</code>
 
| De ''testomgeving'' of ''external test enviroment'' is voor de klant om mee te kunnen kijken. De site die hier staat, is afkomstig van de integratie-omgeving, en bedoeld om te promoveren tot productie-omgeving.
 
| De ''testomgeving'' of ''external test enviroment'' is voor de klant om mee te kunnen kijken. De site die hier staat, is afkomstig van de integratie-omgeving, en bedoeld om te promoveren tot productie-omgeving.
 
Dit stadium sla ik regelmatig over. Vooral voor projecten met een laag risico (bv. weinig complex; contact met de klant gaat gemakkelijk)
 
Dit stadium sla ik regelmatig over. Vooral voor projecten met een laag risico (bv. weinig complex; contact met de klant gaat gemakkelijk)
Regel 76: Regel 84:
 
| Productie-omgeving
 
| Productie-omgeving
 
| Webserver - Hoofddomein
 
| Webserver - Hoofddomein
 +
| <code>naam</code> - Overkill om <code>s4</code> toe te voegen. Dat zou wel kunnen als additionele alias, als ik in de war zou raken
 
| Het eindresultaat: De site die bedoeld is om door klanten bezocht te worden
 
| Het eindresultaat: De site die bedoeld is om door klanten bezocht te worden
 
|}
 
|}
Regel 82: Regel 91:
  
 
* Het komt waarschijnlijk zelden voor, dat ik alle vijf de stadia gebruik. Voor eenvoudige projecten gebruik ik alleen ''s4'', maar meestal een combinatie van ''s2'' en ''s4''.
 
* Het komt waarschijnlijk zelden voor, dat ik alle vijf de stadia gebruik. Voor eenvoudige projecten gebruik ik alleen ''s4'', maar meestal een combinatie van ''s2'' en ''s4''.
* Waar hierboven <code>url</code> wordt genoemd, kun je <code>domeinnaam</code> of <code>projectnaam</code> voor invullen. Meestal gebruik ik deze laatste en vaak zijn dat kortere benamingen dan de bijbehorende domeinnamen: Op die manier weet ik na een half jaar tenminste nog bij welk project een URL hoort.
+
* Waar hierboven <code>naam</code> wordt genoemd, kun je <code>domeinnaam</code> of <code>projectnaam</code> invullen. Meestal gebruik ik deze laatste en vaak zijn dat kortere benamingen dan de bijbehorende domeinnamen: Op die manier weet ik na een half jaar tenminste nog bij welk project een URL hoort.
  
 
=== Vraagstukken ===
 
=== Vraagstukken ===

Versie van 10 jul 2019 10:38

Als je een site aan het ontwikkelen bent, werk je meestal met verschillende versies van dezelfde site. Het aantal sites, de benaming en hun functies, willen nogal eens verschillen. Dit valt onder release management: Een proces om tot een release te komen.

Voorbeelden

Eenvoudig

  1. Ontwikkelomgeving
  2. Externe testomgeving
  3. Productie-omgeving

Complex

[1]:

Environment/Tier Name Description
Local Developer's desktop/workstation
Development/Trunk Development server acting as a sandbox where unit testing may be performed by the developer
Integration Continuous integration build target, or for developer testing of side effects
Testing/Test/QC/Internal Acceptance The environment where interface testing is performed. A quality control team ensures that the new code will not have any impact on the existing functionality and tests major functionalities of the system after deploying the new code in the test environment.
Staging/Stage/Model/Pre-production/External-Client Acceptance/Demo Mirror of production environment
Production/Live Serves end-users/clients

Wat ik zelf gebruik

Stage Naam Omgeving URL Bash-alias Beschrijving
s0 Legacy-omgeving (ik zoek nog een goede naam) Laptop s0 + naam + .dvb. Bv. s0.example.dvb s0.naam Dit is de 'oude' c.q. 'huidige' site. Dit is in situaties dat ik een nieuwe site bouw, ter vervanging van een bestaande site. Vaak instantiëer ik zo'n site om dingen te kunnen overnemen
s1 Ontwikkelomgeving Laptop s1 + naam + .dvb. Bv. s1.example.dvb s1.naam Development of development environment. Dit is waar ik dingen test. Deze omgeving richt ik vaak opnieuw in, omdat-ie vaak een zooitje wordt door allerlei tests. Doorgaans wordt wat ik hier ontwikkel, niet doorgeschoven naar de integratie-omgeving: Als ik iets heb ingericht op de ontwikkelomgeving, maak ik het daarna meestal opnieuw binnen de integratie-omgeving.
s2 Integratie-omgeving Laptop s2 + naam + .dvb. Bv. s2.example.dvb s2.naam De site binnen de integratie-omgeving is bedoeld om doorgeschoven te worden naar de testomgeving en productie-omgeving. Daarom ga ik zorgvulding om met wat er binnen deze omgeving staat. Het is niet bedoeld voor uitprobeersels of tests
s3 Externe testomgeving Webserver - Subdomein Subdomein onder de productie-omgeving. Bv. s3.example.com. Ik gebruik liever niet namen zoals test.example.com of nieuw.example.com, omdat die te hack-gevoelig zijn (je kunt ze namelijk gemakkelijk raden) en niet-professioneel.

Op het moment dat ik nog geen productie-versie van de betreffende site host, dan host ik dit onder devliegendebrigade.nl. Bv. s3.example.devliegendebrigade.nl of s3.projectnaam.devliegendebrigade.nl. Het lijkt overkill om s3 toe te voegen, maar ik denk dat dat juist intuïtief is. Zo snel ik de hosting van de betreffende domeinnaam overneem, migreer ik deze situatie naar de eerste variant (dus met subdomeinen)

s3.naam De testomgeving of external test enviroment is voor de klant om mee te kunnen kijken. De site die hier staat, is afkomstig van de integratie-omgeving, en bedoeld om te promoveren tot productie-omgeving.

Dit stadium sla ik regelmatig over. Vooral voor projecten met een laag risico (bv. weinig complex; contact met de klant gaat gemakkelijk)

s4 Productie-omgeving Webserver - Hoofddomein naam - Overkill om s4 toe te voegen. Dat zou wel kunnen als additionele alias, als ik in de war zou raken Het eindresultaat: De site die bedoeld is om door klanten bezocht te worden

Opmerkingen

  • Het komt waarschijnlijk zelden voor, dat ik alle vijf de stadia gebruik. Voor eenvoudige projecten gebruik ik alleen s4, maar meestal een combinatie van s2 en s4.
  • Waar hierboven naam wordt genoemd, kun je domeinnaam of projectnaam invullen. Meestal gebruik ik deze laatste en vaak zijn dat kortere benamingen dan de bijbehorende domeinnamen: Op die manier weet ik na een half jaar tenminste nog bij welk project een URL hoort.

Vraagstukken

Is het wel handig om met subdomeinen te werken zoals s0.example.dvb? Alternatief zijn bv. s0_example.dvb of example_s0.dvb. Is het ergens extra complex om met subdomeinen te werken? Anders is dit wel heel prettig, want uniform en vermoedelijk gemakkelijk te migreren.

Bronnen