Website Development uitrollen naar live website

[NLAnaconda]

Hallo Tweakers,

Ik maak al een poosje website's en doe iets goed fout. Aanpassingen aan mijn website's doe ik namelijk vrijwel altijd aan mijn "live"/"productie" website.
Ik weet dat het niet goed is en dat je een ontwikkel omgeving er naast moet draaien. Ik doe dit echter nooit omdat ik altijd in de knoop kom en het omslachtig vind werken. Ik weet namelijk als ik een update wil uitrollen van ontwikkel naar productie omgeving niet welke aanpassingen ik ook al weer moet doen.

Moet ik werkelijk elke database aanpassing opschrijven en bij een update weer doorvoeren aan de live database? Ik kom er daar dan vaak achter dat ik iets ben vergeten op te schrijven.

Hoe doen jullie dat? Hoe houd je bij welke aanpassingen je maakt in je ontwikkel omgeving en hoe voer je die door maar je productie website?

(Ik hoop dat de vraag duidelijk is)

[frickY]

Dingen opschrijven kan, maar zoals je al aangeeft is dat foutgevoelig en omslachtig. Daarom kun je dat soort dingen het best automatiseren.
Er zijn tools die 2 databases met elkaar kunnen synchroniseren.

Die tools kun je weer implementeren met tools als phing of grunt, waarmee je het volledige proces van een wijziging live zetten (en dit ongedaan kunnen maken!) kunt scripten, en het letterlijk een kwestie van een druk op een knop wordt.

[ Voor 37% gewijzigd door frickY op 22-08-2013 00:44 ]

[franssie]

als je je veranderingen niet bijhoudt in een log, en de website is voor iemand anders bedoeld dan jezelf - dan ben je een prutser die geen idee geeft wat ie doet en welk gevaar hij/zij is voor de opdrachtgever.
Op je eigen domein kan je wel wat spelen.

[NLAnaconda]

Zijn eigen website's. En dude zo professioneel ben ik ook niet.
Wil alleen weten/leren hoe je dit het beste kan aanpakken.
Gelukkig ben jij met die kennis geboren.

Als je dan ook even verteld hoe je logt en wat je logt dan deel je de aangeboren kennis ook nog een beetje. BVD.

[ Voor 102% gewijzigd door NLAnaconda op 22-08-2013 00:56 ]

[Megamind]

Ligt ook een beetje aan je IDE tegenwoordig.

In Visual Studio heb je namelijk web publishing waarbij je simpelweg met 1 druk op de knop een uitrol doet naar een acceptatie/live-omgeving (inclusief DB wijzigingen).

Er zullen vast wel andere IDE's zijn die sync / publish opties hebben.

Als je het echt goed doet: dev (local) -> test -> acceptatie -> live, maar dat is vaak bij kleine websites niet aan de orde.

[Verwijderd]

Je moet gewoon defensief leren denken.

Stel je voor dat je een aanpassing aan de database moet doen. Een kolom toevoegen of een essentiële waarde wijzigen. Doe dan bijvoorbeeld niet eerst de wijziging, maar schrijf een check die controleert of de wijziging al is uitgevoerd. Uiteraard faalt die check meteen. Vervolgens ga je de wijziging in je developmentomgeving doorvoeren en daarna moet de check slagen. Je revert naar de oude situatie en de check moet weer falen. Je schrijft nu een updatescript en voert dat uit. Nu moet de check weer slagen.

Belangrijk is dat je updatescript je website eerst in maintenance modus zet (geen wijzigingen door eindgebruikers) en dat je aan het eind weer naar productie modus gaat.

Als je je werk goed hebt gedaan kun je het updatescript uitvoeren op je productieomgeving. Idealiter heb je natuurlijk nog een test en acceptatieomgeving, maar dat zal voor privéprojectjes niet erg veel zin hebben.

[NLAnaconda]

Thanks! Hier kan ik wat mee.

[Gomez12]

@Cheatah : TDD is wel zo ongeveer het moeilijkste principe om consequent te hanteren.

Om van in live-prutsen direct over te gaan naar TDD is denk ik iets te veel gevraagd.

Maar simpelweg alles via scripts doorvoeren (ipv direct in de dbase te doen) is al een gigantische verbetering . Dan is het simpelweg enkel maar het script draaien op een andere db.
Die script kan je gewoon opnemen in je VCS

Of je kan het nog basaler aanpakken en een db-inventarisatie script schrijven, deze haalt gewoon alle tabel / db settings op en mikt dit in een leuk txt-filetje. Draai het inventarisatie script op live en op test en met een diff kan je de verschillen al zien.

[Styxxy]

Gomez12 schreef op donderdag 22 augustus 2013 @ 01:10:
@Cheatah : TDD is wel zo ongeveer het moeilijkste principe om consequent te hanteren.

TDD (test-driven development) heeft helemaal niets te maken met het schrijven van "overdrachts-" / wijzigingsscripts om toe te passen op verschillende omgevingen.

Het is gewoon het beste om inderdaad steeds wijzigingen aan de database te scripten alvorens deze uit te voeren. Je kan eventueel de aanpassingen doen gewoon in development, maar steeds noteren wat je hebt gedaan; op die manier kan je nog steeds changescripts maken wanneer je effectief in "productie" wilt deployen.

[Gomez12]

Styxxy schreef op donderdag 22 augustus 2013 @ 01:33:
[...]
TDD (test-driven development) heeft helemaal niets te maken met het schrijven van "overdrachts-" / wijzigingsscripts om toe te passen op verschillende omgevingen.

Mijn opmerking over TDD ging over het volgende stukje :

Stel je voor dat je een aanpassing aan de database moet doen. Een kolom toevoegen of een essentiële waarde wijzigen. Doe dan bijvoorbeeld niet eerst de wijziging, maar schrijf een check die controleert of de wijziging al is uitgevoerd. Uiteraard faalt die check meteen. Vervolgens ga je de wijziging in je developmentomgeving doorvoeren en daarna moet de check slagen. Je revert naar de oude situatie en de check moet weer falen. Je schrijft nu een updatescript en voert dat uit. Nu moet de check weer slagen.

Ik vind het knap dat je hier enkel maar uithaalt dat er een updatescript geschreven moet worden en het hele TDD gedeelte (bolding all mine) mist...

[drm]

Er zitten wel wat overeenkomsten tussen wat Cheatah zegt en TDD, maar TDD is een ontwikkelmethodiek en heeft als methodiek niets te maken met migration. De eerst falende test is de belangrijkste overeenkomst, en die duidt gewoon op logica. Je kunt alleen vaststellen of de uitkomst van een test (wat voor test dan ook) klopt als je beide uitkomsten hebt geverifieerd. M.a.w.: als je niet zeker weet of een test faalt als de omgeving niet aan de gestelde condities voldoet, kun je er ook niet zeker van zijn dat het feit dat hij slaagt een aanwijzing is dat de omgeving wel aan de gestelde condities voldoet. Als dat niet nodig zou zijn zou je immers gewoon een test kunnen downloaden die simpelweg zeg "Hij doet ut!" en die voor alle situaties gebruiken. Het mag duidelijk zijn dat dat geen zin heeft.

Het belangrijkste in het proces is dat je het proces herhaalbaar/reproduceerbaar maakt. Dus, in jouw geval, de productie-omgeving kunt repliceren en daar je scripts op kunt testen. In het geval van databases komt dat dus neer op simpelweg een dump van de database overzetten naar een andere omgeving, daar je updates uitvoeren en kijken of het werkt. Als je dat hele proces automatiseert ben je feitelijk waar je wezen wilt: je kunt namelijk met een druk op de knop kijken of datgene dat je straks wilt gaan doen ook echt zal gaan werken.

Overigens, als je het hebt over ontwikkelen, zorg gewoon dat je een ontwikkelomgeving hebt. Dat is helemaal niet moeilijk. Als je geen lokale installaties van je serversoftware wilt draaien, kan het gewoon zo simpel zijn als een tweede variant van je site op www2.mycooldomain.name draaien en daar op ontwikkelen.

Als je er nog meer over wilt weten / nalezen, zoek dan eens op OTAP, release management, change management, migration management, automated deployment en niet te vergeten version management.

[NLAnaconda]

Thnx drm! Met dat laatste weet ik ook waarop ik moet googlen. :-)

[TheNephilim]

Ook hier nog een groot probleem. We maken veel websites die te klein zijn voor een dergelijke ontwikkel cyclus. Ik wil ook snel naar Git toe en netjes projecten aanmaken in PhpStorm. Helaas is dat allemaal niet zo simpel. Git wel, maar de combinatie tussen Git en PhpStorm zonder dat je een halve dag bezig bent om een project op te zetten.

[Verwijderd]

- Lokaal gaan ontwikkelen.
- Versiebeheer gebruiken bij voorkeur Git.
- Capistrano gebruiken om uit te rollen van development naar staging naar live.
- Verdiepen in Continuous integration (CI)

PS. Zelf gebruik ik Intellij IDEA 12 of Sublime Text 3. Binnen IJ roep ik een capistrano taak aan om mijn wijzigingen uit te rollen naar staging of production inclusief database migraties.

[ Voor 32% gewijzigd door Verwijderd op 22-08-2013 10:54 ]

[kwaakvaak_v2]

NLAnaconda schreef op donderdag 22 augustus 2013 @ 00:38:
Hallo Tweakers,


Hoe doen jullie dat? Hoe houd je bij welke aanpassingen je maakt in je ontwikkel omgeving en hoe voer je die door maar je productie website?

(Ik hoop dat de vraag duidelijk is)

git pull origin en daarna evt. cache:clear, doctrine:schema:update, assetic:dump.

Maar voor die eerste is belangrijkste in deze. Zorg ervoor dat je site in een versie beheer systeem staat en dat je live niet ook dingen hebt lopen aanpassen om het werkend te krijgen.

[Barryvdh]

Ik gebruikt git voor versiebeheer en vaak gebruik ik Laravel met Migrations (http://laravel.com/docs/migrations). Daarmee script je de aanpassingen om te upgraden, maar ook om down te graden. Als je iets verknalt, kan je altijd meteen terug.
Zelfde met live zetten, gebruik ik rocketeer (https://github.com/Anahkiasen/rocketeer), vergelijkbaar met Capistrano denk ik.
Kan je instellen welke taken etc hij moet uitvoeren, zoals laatste versie uit git halen, composer install, database migrations runnen, assets compilen, symlink aanpassen etc. Zo is je website niet offline en kan je direct terug naar een vorige installatie.

[Grijze Vos]

drm schreef op donderdag 22 augustus 2013 @ 02:05:
Er zitten wel wat overeenkomsten tussen wat Cheatah zegt en TDD, maar TDD is een ontwikkelmethodiek en heeft als methodiek niets te maken met migration.

je zou het Test Driven Deployment kunnen noemen. of Test Driven Migration.

[Laurens-R]

Ik kwam net een ad tegen die jouw probleem zeker oplost! Inclusief coole extras Dat hij automated deployments doet is tot daar aan toe... maar die extra's; daar doe ik het voor

(klik om groter te maken)

[ Voor 20% gewijzigd door Laurens-R op 22-08-2013 13:58 ]

[Martijndoes]

Ik heb ook heel lang precies hetzelfde aangeprutst als jij. Veranderingen op de livesite met alle gevolgen van dien. Toen een 'acceptatie' omgeving opgezet maar dan vergeten welke files je allemaal moet wijzigen en alsnog downtime hebben.

Paar maanden geleden heb ik de overstap gemaakt van notepad++ naar eclipse for php. Daarin heb ik verschillende ANT scripts aangemaakt die de uitrol automatisch doet naar een specifieke omgeving.
Dit script maakt een FTP verbinding naar de website, zorgt ervoor dat de config files zijn aangepast zodat ze wijzen naar de juiste db (erg belangrijk) en upload de aangepaste files naar de juiste folders.

Voor database aanpassingen heb ik helaas nog niet zoiets aangemaakt, ik maak dan ook erg weinig database aanpassingen maar voor file aanpassingen werkt dit perfect. Testen gaat veel makkelijker nu en ik merk ook dat ik veel gemakkelijker nu daadwerkelijk op de testomgeving test voor ik een aanpassing maak.

Mocht je het willen kan ik de ANT scripts wel naar je sturen als ik thuis ben. Zijn behoorlijk simpel maar scheelt je toch weer wat werk.

[Barryvdh]

Je kan ook makkelijk zelf iets schrijven voor je database migraties.
In het simpelste geval gewoon in een extra tabel bijhouden en door al je updates heenlopen, totdat je bij dezelfde versie bent:

code:

 switch ($fromVersion) {
    case 0:
        $this->doSql("CREATE TABLE IF NOT EXISTS ....");
        $this->setVersion(1);
    case 1:
        $this->doSql("ALTER TABLE  `table2` ADD  `another_field`  varchar(32) NOT NULL");
        $this->setVersion(2);
    case 2:
    //etc..
}

[Piemol]

Databasewijzigingen doe ik altijd door heel simpel alle statements die ik op de development heb gedraait, in een bestandje op te slaan.
Als een wijziging dan live gezet moet worden, kopieer en plak je de statements in bijv. phpMyAdmin op de live omgeving, en klaar.
Super simpel lijkt me, en na elke update ronde maak je weer een nieuw bestandje aan waar je je queries in opslaat om naar de volgende versie te updaten.

[kwaakvaak_v2]

Ben ik toch blij dat ik gewoon doctrine2 migrations kan gebruiken, hoef ik een stuk minder zelf bij te houden

Dat bij houden is leuk en aardig, maar als je meer dan 10 projecten tegelijkertijd in onderhoud hebt en er met meerdere mensen aan gaat werken is het vragen om dingen die een keertje mis gaan.

[Barryvdh]

kwaakvaak_v2 schreef op donderdag 22 augustus 2013 @ 15:11:
Ben ik toch blij dat ik gewoon doctrine2 migrations kan gebruiken, hoef ik een stuk minder zelf bij te houden

Dat bij houden is leuk en aardig, maar als je meer dan 10 projecten tegelijkertijd in onderhoud hebt en er met meerdere mensen aan gaat werken is het vragen om dingen die een keertje mis gaan.

Dat is natuurlijk ook gewoon een optie, kan je ook los gebruiken: http://docs.doctrine-proj...ference/introduction.html

[Styxxy]

Gomez12 schreef op donderdag 22 augustus 2013 @ 01:43:
[...]
Ik vind het knap dat je hier enkel maar uithaalt dat er een updatescript geschreven moet worden en het hele TDD gedeelte (bolding all mine) mist...

En dat is nog steeds geen TDD. Een "check" schrijven is niet direct Test-Driven Development. Check kan ook slaan op "controle". Hoe dat ik zulke scripts altijd schrijf is: controle of dat de wijziging reeds is doorgevoerd, zo nee, execute wijziging.

[NLAnaconda]

Zo, wat een reacties. Bedankt allemaal voor het opweg helpen.