OTAP & webapplicatie ontwikkeling

[EddoH]

Omdat er binnen ons bedrijf langzaam een verschuiving naar meer web gebaseerde technologieën plaatsvind, en daar nog een gat v.w.b. kennis zit, heb ik een aantal vragen voor de doorgewinterde webdevelopers hier, om er zo achter te komen wat er een beetje 'industriestandaard' is.

Achtergrond: we hebben een aantal (technische) applicaties/services ontwikkeld, die op divers servers draaien. De gebruikte talen & technologieën zijn zeer divers, maar het gaat vaak niet alleen om ´simpele´ websites. Zonder in detail te treden bestaan deze applicaties vaak uit een front-end, een database, en de core service in PHP, Javascript(NodeJS), C++, Java, etc.

Nu staan we voor de taak om ons ontwikkelproces eens drastisch te professionaliseren middels automatische deployments, een 'echte' OTAP-straat (we hebben nu alleen een halfbakken TAP), en meer van de common best practices. In voorbereiding en bij gebrek aan praktische ervaring heb ik hierover wat vragen met als doel zoveel mogelijk zienswijzen en praktische oplossingen te vergaren. De lijst met vragen is groot, maar ik hou het voor nu bij de hoofdvragen. Suggesties voor leesvoer om het een ander zelf uti te zoeken zijn natuurlijk ook welkom.

1. Hoe houden we serverconfiguratie tussen ontwikkeling,test,acceptatie,productie gelijk? Denk hierbij aan firewall rules, linux gebruikers/rechten, PHP versies, etc.
   Is dit handwerk of gebruiken je hiervoor voorgebakken images? En hoe gaan je om met de verschillen die er wel altijd zijn, zoals domeinnamen, ssl certificaten en ip-adressen?
2. Hoe doen we versiebeheer van database veranderingen, en hoe deployen we die automatisch van test naar acceptatie en productie?
3. Als we een ontwikkeling aan een project doen, veranderen er vaak verschillende dingen: Frontend code, backend code, database schema's en serverconfiguraties.
   Hoe houden we deze veranderingen bij elkaar en hoe rollen jullie die in 1 keer uit van test naar bijvoorbeeld acceptatie en verder?
4. Bij een mislukte uitrol naar acceptatie, inclusief serverconfiguratieveranderingen-> hoe maken we die ongedaan zodat acceptatie zoveel mogelijk hetzelfde blijft als productie?
5. Welke tools kunnen we voor bovenstaande vraagstukken gebruiken?

Alvast bedankt voor de input

[Anoniem: 289295]

Eigenlijk vraag je: hoe organiseer ik mijn volledig technisch (applicatie)beheer. Als je zulke basale vragen niet kunt beantwoorden zou ik het zeker niet zelf gaan doen maar uitbesteden. Vragen om problemen, anders.

[Nvidiot]

Je zou naar Vagrant (https://www.vagrantup.com/) kunnen kijken voor het geautomatiseerd opzetten van de verschillende omgevingen. Hiermee kun je automatisch een VM aanmaken met de gewenste configuratie.

[EddoH]

Anoniem: 289295 schreef op woensdag 01 oktober 2014 @ 13:48:
Eigenlijk vraag je: hoe organiseer ik mijn volledig technisch (applicatie)beheer. Als je zulke basale vragen niet kunt beantwoorden zou ik het zeker niet zelf gaan doen maar uitbesteden. Vragen om problemen, anders.

Uitbesteden is zeker een optie. Verder heb ik zelf zeker wel een idee hoe ik het een en ander aan zou pakken, maar ben op zoek naar ervaringen van buiten. Zo basaal zijn deze vragen toch niet overigens?

Daarnaast: alleen uitbesteden omdat we er nog weinig ervaring in hebben is geen reden vind ik. Toch bedankt voor je reactie

[Cloud]

Poeh dit is wel echt héél breed.

Punt 1 tja je moet gewoon beginnen. Versies/configuraties moet je gewoon gelijk houden. Hoe meer verschillen, hoe groter je je testoppervlak (bij gebrek aan een beter woord) maakt. In theorie zou het enige verschil de DB connectie moeten zijn. Het idee is juist dat het doorlopen van de OTAP geen problemen op zou moeten leveren maar de zaak gewoon uitvoerig getest wordt voordat het bij de P aankomt. Als de OTAP omgevingen allemaal anders zijn, doe je een (groot) deel van het idee van de OTAP-strategie al teniet.

Punt 2 zou ik toch echt zoeken in het framework wat je gebruikt, of je moet zoiets zelf gaan schrijven (maar dan ben je nog lang niet klaar).

Punt 3 kun je (in elk geval deels) via je source control regelen maar het meest eenvoudig is om altijd alles opnieuw uit te rollen, niet alleen de veranderde zaken. Indien niet mogelijk, gebruik je source control om een lijst van changes te maken sinds de laatste release en zie dat uit te rollen.

Punt 4 zou niet een groot probleem moeten zijn. Dáár is de acceptatieomgeving tenslotte voor. In principe, als alles voor zover mogelijk gelijk is, is dezelfde versie eerst al langs de T geweest. Als dat slaagt zouden de A en P ook moeten slagen.

Punt 5 hangt af van jullie framework en database maar ik begrijp dat het PHP is. Daar kan ik verder weinig nuttigs over zeggen

[ Voor 10% gewijzigd door Cloud op 01-10-2014 13:55 ]

[EddoH]

Cloud schreef op woensdag 01 oktober 2014 @ 13:54:
Poeh dit is wel echt héél breed.

Ben ik me van bewust Heb het expres niet al te specifiek gemaakt omsdat ik jusit op zoek ben naar algemene/abstracte aanpakken.

Punt 1 tja je moet gewoon beginnen. Versies/configuraties moet je gewoon gelijk houden. Hoe meer verschillen, hoe groter je je testoppervlak (bij gebrek aan een beter woord) maakt. In theorie zou het enige verschil de DB connectie moeten zijn. Het idee is juist dat het doorlopen van de OTAP geen problemen op zou moeten leveren maar de zaak gewoon uitvoerig getest wordt voordat het bij de P aankomt. Als de OTAP omgevingen allemaal anders zijn, doe je een (groot) deel van het idee van de OTAP-strategie al teniet.

We houden het nu grotendeels 'met de hand' gelijk, alleen gaat hier veel tijd inzitten zodat.

Punt 2 zou ik toch echt zoeken in het framework wat je gebruikt, of je moet zoiets zelf gaan schrijven (maar dan ben je nog lang niet klaar).

We gebruiken geen vast framework, maar een aparte Postgres database. Nu doen we het door patches te schrijven die incrementeel de database veranderingen doorvoeren. Ik vroeg me af of hier goede tooling voor is.

Punt 3 kun je (in elk geval deels) via je source control regelen maar het meest eenvoudig is om altijd alles opnieuw uit te rollen, niet alleen de veranderde zaken. Indien niet mogelijk, gebruik je source control om een lijst van changes te maken sinds de laatste release en zie dat uit te rollen.

De code lukt wel. het probleem zit hem in bijvoorbeeld firewall configuratie die bij een bepaalde set commits in git hoort. Nu passen we die handmatig of via een script toe bij de uitrol. Maar het is niet (goed) gedocumenteerd.

Punt 4 zou niet een groot probleem moeten zijn. Dáár is de acceptatieomgeving tenslotte voor. In principe, als alles voor zover mogelijk gelijk is, is dezelfde versie eerst al langs de T geweest. Als dat slaagt zouden de A en P ook moeten slagen.

Goede opmerking. Deze vraag is misschien ook te 'wat als-ig'

Punt 5 hangt af van jullie framework en database maar ik begrijp dat het PHP is. Daar kan ik verder weinig nuttigs over zeggen

Geen 1 framework, maar eerder 5 of 6

Bedankt voor je opmerkingen, ik kan er wel wat mee.

[Kalentum]

1. Gebruik tools als Vagrant, Chef of Puppet. Je hebt dan configuratiebestanden die beschrijven wat een front end server is of een database server. Dus de commando's om de boel te installeren en te configureren staan dan in een soort script file die je in versiebeheer kan bijhouden

2. Database migraties. Zijn verschillende opties voor en het is ook niet vreselijk ingewikkeld. Doorgaans beschrijf je (in php, of plain sql, of een xml file) een 'up': de SQL-statements (en evt conversies) die nodig zijn om van database config XXX naar YYY te gaan. En je hebt een 'down' om de migratie weer ongedaan te maken. Ik ben zelf ooit voor Mysql met https://github.com/davesloan/mysql-php-migrations dit begonnen en heb het omgebouwd voor PostgreSQL.

3. Vagrant, Chef of Puppet. Ik weet in elk geval dat Puppet config wijzigingen kan pushen. Ik gebruik ze momenteel niet: als er een configwijziging is wordt dat gewoon handmatig doorgevoerd.

4. Niet alleen de wijziging van A naar B vastleggen, maar ook de migratie terug. Evt kun je een snapshot van de server maken (als je tenminste virtual servers gebruikt) en die restoren om terug te gaan.

[EddoH]

Top rutgerw. Exact het soort antwoorden waar ik naar op zoek ben. Ik zal sowieso eens in Chef/Puppet duiken.

[ Voor 3% gewijzigd door EddoH op 01-10-2014 14:52 ]