[Best Practice] Deployen website naar productie

[PdeBie]

Hoi allen,

wij zijn momenteel in ons bedrijf een aantal zaken aan het herzien/professionaliseren. Een belangrijk deel daarvan is het uitrollen van een update van onze applicatie.

Huidige situatie:
- ontwikkeling vind plaats op een lokale pc met ASP.NET development server
- een webserver als testomgeving en een andere webserver voor productie
- een SQL server voor development en een SQL server waar zowel de test- als productie database op draaien

Na een release naar onze testomgeving gaat onze tester alles na. Als blijkt dat alles goedgekeurd is, vind er een live (productie) release plaats.

Onze productie releases vinden plaats als volgt:
- app_offline.htm wordt ingeschakeld. Het is niet noodzakelijk dat onze applicatie 24/7 bereikbaar is. Uiteindelijk proberen we dit natuurlijk wel zoveel mogelijk.
- aantal scheduled tasks op de productie server worden uitgeschakeld.
- backup maken van productie omgeving (zowel webserver als database)
- productie database updaten middels APEX SQL Diff, gevolgd door eventuele query's uit te voeren voor het vullen van benodigde data.
- kopieren van de files voor de applicatie. Dit gebeurt nu handmatig.
- scheduled tasks op de productie server worden ingeschakeld.
- app_offline.htm uitschakelen
- applicatie testen (inmiddels zijn er ook weer eindgebruikers aan het inloggen).


Zoals jullie zien zijn dit redelijk wat stappen en is het op sommige punten fout/probleem gevoelig. Bijvoorbeeld dat de eindgebruikers al aan het inloggen zijn als wij nog aan het testen zijn. Ook het handmatig kopiëren van files is foutgevoelig. Zo kunnen er bestanden worden vergeten.

Dit willen wij anders gaan doen. Het moet zo zijn dat wij een update uit kunnen voeren met een of enkele klikken op een knop en klaar. Niks geen gedoe meer met het handmatig wijzigen van zaken.

Nu ben ik benieuwd hoe jullie productie releases uitvoeren en wat jullie als verbeteringen zien in onze aanpak. Een van de dingen die we zelf al opgesomd hebben, is het maken van batch files voor het kopiëren van de bestanden.
Maar hoe lossen we het probleem op met het testen van de productie release? Als daar problemen in zitten, hebben onze eindgebruikers daar ook last van. En hoe je het went of keert, het komt soms nou eenmaal in ons (soms) gek makende wereldje voor dat een test omgeving 100% goed werkt en het op productie het toch net even anders werkt.

Ik ben benieuwd naar de reacties. Alvast bedankt voor het lezen van deze lap tekst

[djluc]

Zit je code in versiebeheer? Daar begint het in de meeste gevallen. Heb je verder test omgeving(en)?

[messi]

Wij zijn een Ruby club en maken gebruik van capistrano. Deze tool deployed onze applicaties vrijwel automatisch naar de productie servers. Maar het deployen is de laatste stap van ons process.

Alle wijzigingen worden in develop gemerged door middel van Pull Requests op github. Onze CI server test deze pullrequests en laat op github weten of alle tests gepassed zijn.

Als 2 of meer mensen een +1 geven op de pullrequest kan deze ingemerged worden op develop. Daarna gaat de CI nogmaals alles testen. (Bij een pullrequest wordt de testcoverage en sanity van de code beoordeeld).

Als alles groen is, kan het naar de staging omgeving waarna de klant het kan testen. Als deze een OK geeft, kan het naar master, waarna de CI het nogmaals test.

Als al deze stappen doorgelopen zijn, is het een kwestie van

code:

 cap production deploy

typen en de hele bende gaat naar productie.


Capistrano doet basically het volgende:

SSH-en naar productie, git uitchecken, assets compilen, configuratie symlinken, andere taken uitvoeren (background processen re-starten, cronjobs instellen, migraties draaien etc. etc).

Als dit klaar is symlinked capistrano de nieuwe versie naar een "current" folder waarna de webserver detecteerd dat er een nieuwe versie is en deze inlaad.

Mocht er iets fout zijn, dan kunnen we doormiddel van cap production deploy:rollback de oude folder weer symlinken en het probleem rustig debuggen

[ Voor 23% gewijzigd door messi op 04-04-2013 12:22 ]

[Cor453]

Ja, versiebeheer moet je goed opzetten. Gebruik je ook Visual Studio? Ik weet dat in de nieuwere (2010/2012) releases er een hele goede publish tool zit sowieso. Daarnaast: hoeveel mensen moeten testen? Kun je dan niet een soort tijdelijke whitelist aanzetten?

[PdeBie]

code zit uiteraard in versie beheer. Visual Sourcesafe gebruiken we.
Wij werken nu met VS2010, maar zijn langzaamaan de stap naar VS2012 aan het maken.

De omgevingen die we hebben staan omschreven in de eerste post.

We testen met 3 personen de productie release. Daarbij hebben we een testplan waarbij we door de webapplicatie heen klikken/werken om te kijken of alles nog naar behoren werkt.

We zijn aan het kijken of we een soort van whitelist op IP basis kunnen maken. Dus dat we alleen vanaf ons kantoor kunnen inloggen en de rest nog geredirect wordt naar de 'er is onderhoud' pagina.

[ Voor 6% gewijzigd door PdeBie op 04-04-2013 13:20 ]

[Cor453]

pdebie schreef op donderdag 04 april 2013 @ 13:19:

We zijn aan het kijken of we een soort van whitelist op IP basis kunnen maken. Dus dat we alleen vanaf ons kantoor kunnen inloggen en de rest nog geredirect wordt naar de 'er is onderhoud' pagina.

Dat zou ik doen ja, dat werkt denk ik het beste. Zo is er minimale kans op fouten van buiten denk ik.

[YopY]

Ten eerste, zoals ook aangegeven wordt, zoek naar deployment automation tools, ze komen in veel verschillende smaken (van scriptjes tot volledige GUI omgevingen); ik ben niet zo bekend met .NET deployments, verder, dus dat is een uitzoekklus.

Ten tweede, bouw een smoke test; een test die het handwerk vervangt met iets dat automatisch door de applicatie heen klikt om het meerendeel van de verificaties die jullie nu met de hand doen te vervangen. Een handmatige check is natuurlijk nooit verkeerd. Een testplan kun je ook in code representeren.

De stelregel is "Three times and you automate". Drie keer door de applicatie klikken? Automatiseren. Drie keer een handmatige deploy, copy/paste actie, etc? Automatiseren.

[D-Raven]

Klinkt alsof je met een combinatie van Nant en powershell al een heel eind moet kunnen komen. Tevens, misschien is dit obvious, maar werk vanuit een staging area. Dat wil zeggen een vaste plek waar je je deployment assets neerzet, dus je sql update scripts (ik neem aan dat je APEX dingetje vast wel een sql script kan genereren) en wat je nog meer nodig hebt voor die specifieke build. Vervolgens start je je deployment script (NANT oid) , of je CI server pakt het op.
Tevens voor best practise deploy vanuit je versie beheer systeem, dus dat je deployment script de te deployen versie uit versiebeheer trekt en deze compileert + evt tests doet, en niet dat iemand handmatig gecompileerde binairy's oid gaat zitten kopieren. Kinda defeats the purpose... (kom het nog teveel tegen..).

[Douweegbertje]

Wat is de rede dat je op prod. server nog moet gaan testen?

Bijvoorbeeld dat de eindgebruikers al aan het inloggen zijn als wij nog aan het testen zijn

test server dient 100% replica te zijn van de prod. Daar moet je op testen, dan zou het feitelijk gezien perfect moeten werken op de prod. Hoogstens doe je nog een simpele test-case.

Ook het handmatig kopiëren van files is foutgevoelig. Zo kunnen er bestanden worden vergeten.

Met een beetje versie beheer kun je gewoon de juiste files pakken?
Daarnaast zijn er wel oplossingen voor, maar in feite met de juiste workflow kun je dit redelijk handmatig doen.

Dit willen wij anders gaan doen. Het moet zo zijn dat wij een update uit kunnen voeren met een of enkele klikken op een knop en klaar. Niks geen gedoe meer met het handmatig wijzigen van zaken.

Dit is wel een hele ideale situatie wat je in feite al een beetje uit je hoofd moet zetten.
In feite mag je het zo zien: 95% ontwikkelen en dan die 5% voor het deployen. Dit hoort er gewoon bij.
Je kunt dingen automatiseren, maar het is nogal 'tricky' om met 1 druk op de knop heel je stuff op de prod. server te gooien.
Het gemakkelijker maken, dat kan zeker.

----------------

Bij 'ons' is het ook niet ideaal, maar het werkt.
Versie beheer, en 1 iemand is hier 'hoofd' van.

- We doen commits en uiteindelijk pushed hij het een keer naar de prod server.
Testen is dan allemaal al gebeurt, want dat kan op de ontwikkel server.

- Qua databases kun je dit al gewoon op de prod. server zetten. Waarom zou je niet extra tables of colums neer kunnen zetten? Dit heeft geen invloed (tenzij je colums count, en je een colum er tussen heb gezet)
Dit gebeurt vaak al voordat de files er niet eens staan.

- backups zijn niet nodig, dit staat in de versiebeheer en mocht er echt een major fuckup komen, worden er dagelijks backups gemaakt.

- Goed bijhouden welke files geupload moeten worden, sorteren op last changed en goan.

- Vervolgens even snel langs verschillende pagina's of het allemaal er nog staat, en het is goed.

Daarnaast hebben we gewoon aparte connection files, dus in feite veranderd er niets boeiends.

[ Voor 59% gewijzigd door Douweegbertje op 04-04-2013 23:31 ]

[PdeBie]

douweegbertje schreef op donderdag 04 april 2013 @ 23:22:
Wat is de rede dat je op prod. server nog moet gaan testen?

[...]

test server dient 100% replica te zijn van de prod. Daar moet je op testen, dan zou het feitelijk gezien perfect moeten werken op de prod. Hoogstens doe je nog een simpele test-case.

Puur ter controle. Controleren is beter dan vertrouwen is ons motto hier. Test is een replica van de prod., maar dan nog. We willen gewoon voorkomen dat de eindgebruiker ongewenste resultaten krijgt.

douweegbertje schreef op donderdag 04 april 2013 @ 23:22:
[...]

Met een beetje versie beheer kun je gewoon de juiste files pakken?
Daarnaast zijn er wel oplossingen voor, maar in feite met de juiste workflow kun je dit redelijk handmatig doen.

Daarom dat we dus met batch files o.i.d. gaan werken, want handmatig slepen in windows verkenner kan echt niet meer


Maar ik neem al deze tips mee in ons volgende overleg hierover. Eens kijken waar we op uit komen.

D-Raven schreef op donderdag 04 april 2013 @ 22:45:
Tevens, misschien is dit obvious, maar werk vanuit een staging area. Dat wil zeggen een vaste plek waar je je deployment assets neerzet, dus je sql update scripts (ik neem aan dat je APEX dingetje vast wel een sql script kan genereren) en wat je nog meer nodig hebt voor die specifieke build.

APEX SQL genereert inderdaad een script (althans, dat is een van de mogelijkheden er in, maar wij doen dat ja).
Staging area hebben wij (nog) niet, maar is tijdens ons overleg hierover al wel een keer geroepen. Om daar nou echter een aparte machine voor neer te zetten is te duur, dus zou zo'n staging area op dezelfde machine kunnen als de productie of testomgeving? Of is dat een afrader?

[ Voor 26% gewijzigd door PdeBie op 05-04-2013 08:49 ]

[leuk_he]

Zolang je sequentieel en periodiek changes uitrolt zal het meestal wel werken. Zorg in ieder geval voor een versie beheer systeem waar je wat aan hebt. Kun je ook scripts per scherm maken? (apexexportsplitter?)

Maar de echte problemen komen als er "kleine" bugfixes de grote releases gaan inhalen. In jouw beschrijving als je tijdens het testen op produktie fouten tegenkomt. (en meteen dus even fixed), maar vergeet deze op test en/of ontwikkel uit te rollen.

Houd dus een goed logboek bij wat er gebeurd is. Of je dit automatiseert, opneemt in de change procedure, of in een simpele history.txt file is jouw keuze.

En ja, uiteraard kun je meerdere omgevingen op 1 database draaien. (meerdere workspaces?).

[xTmPizzaMan]

messi schreef op donderdag 04 april 2013 @ 12:20:
Wij zijn een Ruby club en maken gebruik van capistrano.....

Het heerlijke van capistrano is dat het ook rollbacks doet, mocht er toch iets fout gaat tijdens het deployen in productie. Daardoor blijft de website beschikbaar. Ook heb je 0 downtime deployment

[HMS]

pdebie schreef op donderdag 04 april 2013 @ 13:19:
We zijn aan het kijken of we een soort van whitelist op IP basis kunnen maken. Dus dat we alleen vanaf ons kantoor kunnen inloggen en de rest nog geredirect wordt naar de 'er is onderhoud' pagina.

Je zou ook een extra IIS site kunnen maken als staging omgeving, zodra je dan al je test werk gedaan hebt switch je de productie omgeving om naar de staging omgeving.

Hier zijn natuurlijk ook variaties op te verzinnen, bijvoorbeeld: switch de productie omgeving om naar een aparte IIS website die een 'er is onderhoud' pagina laat zien. Zodra je dan klaar bent switch je dat gewoon weer terug en is de boel weer online.

[steffex]

Je zou eens kunnen kijken naar een DTAP-straat (http://en.wikipedia.org/w...acceptance_and_production). Op die manier hoef je ook niet echt meer te testen op de productie omgeving.

En zorg dat je automatisch gaat testen, scheelt een hoop tijd. Hier op kantoor hebben we 2 soorten automatische tests. Unit tests (snelle tests) en functional tests (langzame tests). Ik draai lokaal alleen de unit tests en laat Jenkins de functional tests draaien. Dit gebeurt hier op elke check-in.

[PdeBie]

HMS schreef op vrijdag 05 april 2013 @ 13:00:
[...]

Hier zijn natuurlijk ook variaties op te verzinnen, bijvoorbeeld: switch de productie omgeving om naar een aparte IIS website die een 'er is onderhoud' pagina laat zien. Zodra je dan klaar bent switch je dat gewoon weer terug en is de boel weer online.

Daar hebben we ook aan zitten denken. Is ook wat fijner dan de app_offline aan te zetten, want het bedrijf wat onze servers beheert krijgt constant uptrends meldingen als wij app_offline aanzetten. Uiteraard lichten wij ze van tevoren in dat we een update gaan doen, maar praktisch is anders.

[messi]

steffex schreef op vrijdag 05 april 2013 @ 13:10:
Je zou eens kunnen kijken naar een DTAP-straat (http://en.wikipedia.org/w...acceptance_and_production). Op die manier hoef je ook niet echt meer te testen op de productie omgeving.

En zorg dat je automatisch gaat testen, scheelt een hoop tijd. Hier op kantoor hebben we 2 soorten automatische tests. Unit tests (snelle tests) en functional tests (langzame tests). Ik draai lokaal alleen de unit tests en laat Jenkins de functional tests draaien. Dit gebeurt hier op elke check-in.

Same here, we hebben unit tests en acceptance tests, wat basically een webkit driver is die door de site klikt en de resultaten checked