Staging (site development) - 2019
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.
Algemeen
Niet alle stadia nodig
Ik gebruik lang niet altijd alle vijf de stadia. Voor eenvoudige projecten gebruik ik alleen s4, en vaak een combinatie van s2 en s4.
Projectcodes
Regelmatig verwijs ik niet naar projecten met de URL, maar met een projectcode. Bv. Kroll ipv. Psychotherapiepraktijk-kroll-moll-vroll.lol. Dat creëert ambivalentie, vooral als ik na een half jaar niet meer weet wat de projectnaam was → Boeit niet: Via vim ~/.bashrc kom ik er snel weer achter
Bash-aliases
Bash-aliases kunnen zowel punten als underscores bevatten. Meestal standaardiseer ik op underscores, maar voor Bash-aliasses gebruik ik liever punten, omdat dat aansluit bij de URL's, en daar verwijzen ze immers naar. Verwarrend? Dan gewoon allebei als alias gebruiken.
Meer legacy-sites?
Stel dat ik voor een project al sites s0, s1, etc. heb, en dat er nu een nieuwe versie komt. Uiteraard worden s1 tot en met s5 geleidelijk vervangen, maar hoe zit het met s0? Er komt nu namelijk een legacy-site bij.
- Ik nummer die door met negatieve nummers. Ziet er niet zo mooi uit, maar is wel logisch en practisch, want daar is ruimte
- Zo'n nieuwe legacy-site zou ik
s-1kunnen noemen, maar dat is eigenlijk niet logisch - Logischer: De bestaande site
s0hernoemen naars-1, en de huidiges4klonen naars0- Dat is immers de 'actuele' legacy-site. Dit is alleen iets meer werk, omdat ik een site moet migreren. Op het moment dat er bv. 5 legacy-sites zijn, moet ik die allemaal migreren - Het zij zo.
Backups
- Ik maak regelmatig backups van S2. Die staan in de projectmap van het betreffende project
- Ik maak doorgaans nooit backups van S1. S1 is om te ontwikkelen en te testen. Zo snel een S1-site om zeep gaat, installeer ik S2 daar overheen
- S3 & S4 worden meegenomen in de backup-beleid van de betreffende servers.
Sinds 15 juli 2019
Zie het eerdere systeem hieronder voor details & uitleg:
| Stage | Naam | Omgeving | URL | Bash-alias | Database-naam | Wachtwoord-suffix |
|---|---|---|---|---|---|---|
| S0 (locaal) | Legacy | Laptop | example.s0 | example.s0 of <projectcode>.s0 | example_s0 | ex |
| S0 (public) | Legacy | Server | s0.example.com of
example_s0.devliegendebrigade.nl |
example.s0 of <projectcode>.s0 | example_s0 | ex |
| S1 | Development | Laptop | example.s1 | example.s1 of <projectcode>.s1 | example_s1 | ex |
| S2 | Integration | Laptop | example.s2 | example.s2 of <projectcode>.s2 | example_s2 | ex |
| S3 | External testing | Server | s3.example.com of
example_s3.devliegendebrigade.nl |
example.s3 of <projectcode>.s3 | example_s3 | ex |
| S4 | Production | Server | example.com | example of <projectcode>.s3 | example_com | ex |
Motieven tav. aanpassingen sinds vorige systeem
- Alfabetisch Handig als de verschillende stages van een site bij elkaar staan in alfabetische overzichten. Dit geldt voor URL's en voor db-namen. Daarom handiger om de staging-codes achter de url's of namen te voegen, in plaats van ervoor
- Korter? Locaal gebruik ik de extentie
.dvb. Daar kan ik ook de staging-codes voor gebruiken. Wel zo'n elegante en efficiënte oplossing. En als ik het ooit vergeet, hoef ik alleen maarls /var/wwwte doen - Twee keer S0? Ja, want van ondergeschikt belang. Dit boeit gewoon niet én komt bijna nooit voor.
Begin juli 2019
| Stage | Naam | Omgeving | URL | Bash-alias | Database-naam | Beschrijving |
|---|---|---|---|---|---|---|
| s0 | Legacy-omgeving (ik zoek nog een goede naam) | Laptop | s0 + naam + .dvb. Bv. s0.example.dvb
|
s0.naam
|
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
|
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
|
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 |
s3.naam
|
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 | Uiteindelijke URL | naam
|
Letterlijk de URL, maar met underscores ipv. punten | Het eindresultaat: De site die bedoeld is om door klanten bezocht te worden |