Beste manier website publishen en beheren

[Qlii256]

Beste

Ik gebruik nu al een tijdje GIT met een remote server waar ik alles naar push. Ik beschik over 2 domeinnamen, namelijk een dev.example.com en een example.com.

Samen met een andere developer schrijven we en pushen we af en toe onze updates naar de remote server. Het is dan ook vanzelfsprekend dat we eerst een pull uitvoeren om de wijzigingen die op de server staan te verkrijgen.

Wat wij ons nu afvragen en waar we al een tijdje naar op zoek zijn is een oplossing voor het volgende probleem:

• Werk je best elk met een local webserver en database of werk je beiden via FTP naar de dev.example.com? (hierbij overschrijf je telkens als je saved wat niet handig is)
• Heb je elk een eigen db en een release db (die dus voor example.com gebruikt wordt)
• Hoe update/publish ik best mijn website naar de live server (example.com)? Want ik wil ook de db naar de live server krijgen en de config-files moeten natuurlijk ook naar de juiste db linken (ander ip).

Dat zijn een aantal vragen die ik en mijn vriend maar niet opgelost krijgen. Ik vraag me af hoe andere grote sites als Tweakers dit doen. Laat me a.u.b. iets weten hoe u het doet om samen te werken en dan vervolgens een complete dev-versie te publishen naar de live site.

Wij maken beiden gebruik van Netbeans omdat daar een zeer goede GIT-support inzit.

[Verwijderd]

Je zorgt er voor dat je compleet lokaal werkt. Uitrollen naar dev.example.com (staging) doe je bij voorkeur via capistrano inclusief database migraties. Staging/live hebben een eigen database. De config zou ik als example opnemen in Git. config.yml.example en config.yml ignoren.

[Qlii256]

Cagalli, bedankt voor je reactie. Ik heb even zitten kijken naar Capistrano en dat is precies wat ik zoek! Enige wat ik niet helemaal snap is dat laatste met die config.yml.example enzo. Ik gebruik trouwens normaal php files (config.php), maar dat zal wel niets uitmaken.

Bedoel je nu dat ik in GIT moet instellen dat hij config.php ignored? Wat bedoel je dan met die .example?

[Pkunk]

Bij ons werkt het ongeveer zo:

Elke developer heeft de database lokaal draaien. Op het moment dat er een stukje is bijgebouwd word dat naar de test omgeving gepushed (liefst d.m.v. git flow). Als het even kan naar een continuous integration server zoals TeamCity. Die testomgeving heeft ook zijn eigen database. Het is de verantwoordelijkheid van de developer die de aanpassingen pushed om ervoor te zorgen dat de test database de nodige aanpassingen heeft. Dat gebeurt doorgaans door scripts of frameworks die de database automagisch modelleren a.d.v. je code. Op de test omgeving worden een zwik tests gedraaid en als dit allemaal in orde is kan het naar een acceptatie omgeving waar de klant kan testen. Is het ok, dan kan het naar live. Bij sommige projecten wordt dit ook allemaal met teamcity geregeld. Bij een push naar develop doet TC automagisch een pull en gaat unittests e.d. runnen. Met een druk op de knop kan dit dan naar acc of live gedeployed worden. Maarja.. soms wil de klant zelf op het knopje drukken en mogen wij er niet bij en dan moet je deployment packages naar de hosting sturen of ander soort ellende..

[DXaroth]

Wij gebruiken hier fabric voor ( www.fabfile.org ), mede omdat python (in tegenstelling tot ruby) op debian-based distros ingebakken zit (voor apt), dus de dependency chain wordt daarmee niet onnodig groot.

Het deployen van onze omgevingen (van dev naar test, van test naar acceptatie en van acceptatie naar productie) gaat via strikte regels; dit mede omdat er per omgeving 1 systeem is dat in verbinding staat met dev, en dat zijn de deployment systemen... deze halen de laatste code van dev, compilen waar nodig, en pushen het naar de juiste systemen..

[Barryvdh]

Beetje vergelijkbaar met Website Development uitrollen naar live website

Database wijzigingen kan je bijhouden in migratiebestanden, zodat je elke update makkelijk overal door kan voeren op de database.

Verder inderdaad lokaal werken, na testen etc pushen na je staging server en als dat goed is, op dezelfde manier pushen naar je productie server.
Met capistrano (of net wat je gebruikt, ik gebruik Laravel met Rocketeer) kan je dan ook aangeven wat je voor/na de deploy moet doen, zoals dus je database migraties uitvoeren, rechten goedzetten, assets builden.

Ik zou je configuratie wel in git bijhouden, maar afhankelijk van je domein/server de goede config ophalen. Zo kan je lokaal je error reporting aanzetten en caching uitzetten, en op je dev (en staging) server dus een andere database/emailadres etc gebruiken.

Met Capistrano etc heb je ook het voordeel dat je per release een mapje hebt, dus als je toch een fout in je productie versie hebt zitten, kan je direct terug naar de vorige versie. Ook kan je (doordat je gewoon je symlink aanpast, zodra de deploy klaar is), direct switchen zonder downtime.

[Qlii256]

Bedankt iedereen voor de reacties! Ik heb even het andere topic bekeken en moet zeggen dat ik al iets wijzer geworden ben. Toch snap ik het niet helemaal goed. Al die verschillende programma's die je dan door elkaar heen moet gebruiken. Sommigen kan je dan koppelen met GIT, anderen weer niet.

Als ik het goed begrijp moet ik dus volgende opstelling hebben:

- Lokaal, webserver + database + GIT (development)
- Test, webserver + database + GIT (testing/staging)
- Live, webserver + database + GIT (live website)

Ik werk dus enkel lokaal en voer commits uit. Als ik een bepaalde functie afgewerkt heb pull ik van de remote GIT server waarna ik vervolgens een push uitvoer naar die remote GIT server. Daarna moet ik met een programma (hier loopt het dus nog mis) de laatste versie van de remote GIT server halen en kopiëren (alsook de database wijzigingen zonder natuurlijk de complete database te overschrijven. Data hoeft natuurlijk (niet van alle tabellen) overgenomen worden, meestal alleen de structuur van de tabellen.) naar de test/staging server.

Daarop wordt alles grondig getest. Indien de testen volledig geslaagd zijn moet ik dus hetzelfde uitvoeren als met de test maar dan naar de live server. En doe ik dan vanaf de test naar de live of ook vanaf de remote GIT naar de live?

Hoe kan ik dus het best in een programma mijn databasewijzigingen bijhouden en die laten updaten samen met de laatste remote GIT repository naar de test/staging of de live server?

Bedankt alvast voor de informatie!

[Barryvdh]

De testserver hoef je in principe niet persé te doen voor kleine websites enzo, als je lokale omgeving en webserver goed overeen komen, maar het kan wel fouten voorkomen, dus voor grotere applicaties wel veiliger.

Je kan in principe ook zelf gewoon vanaf test/productieserver een git pull doen om de laatste versie op te halen.

Zoals in het andere topic ook gezegd wordt, je kan je migrations bijhouden, welke gewoon scripts zijn die je uitvoert, waarmee de tabel opgebouwd/aangepast wordt. In een extra tabel/configuratie hou je dan bij welke migraties je hebt uitgevoerd en met het deployen run je dan alle openstaande migraties, zodat je productieserver up-to-date is met je code. Die migraties zet je dus ook gewoon in Git.
Je kan dat zelf schrijven of kijken naar Doctrine Migrations (http://docs.doctrine-proj...ference/introduction.html) of andere scripts (eerste hits op packagist.org geven http://phinx.org/ en https://github.com/davedevelopment/phpmig bijvoorbeeld)