Website versie beheer

[x-force]

Ik heb een vraag met betrekking versie beheer van een website. Ik werk samen met vier mensen (op verschillende locaties en disciplines) aan de website.

We werken op dit moment met twee omgevingen. 1 test en 1 live omgeving. Het gezamenlijk werken aan de zelfde website is geen probleem. Er zijn duidelijke afspraken wie wat wanneer doet. We maken dus ook geen gebruik van svn.

Nu is het ontwikkel traject simpel. Samen met de klant bespreken we een brok functionaliteit. Wij maken dat eerst in de test omgeving. Nadat het af is testen wij zelf samen met de klant. Is alles goed bevonden gaat de site live. Tot zo ver gaat het goed. Maar nu halve wegen in het ontwikkel proces van nieuwe functionaliteit wil de klant met spoed een aantal kleine dingen aanpassen. Op dat moment ligt de testomgeving op een hoop (we zijn bezig met ontwikkelen en functionaliteit werkt nog niet).

Op dit moment zitten we met een probleem. Gaan we dit live aanpassen met risico dat er dingen fout gaan? Gaan we dit in de testomgeving aanpassen tussen de nieuwe functionaliteit door en geeft veel problemen met live zetten. Delen van een pagina moet dan worden live gezet. Een derde optie is dan een tweede testomgeving maken en daarin het aanpassen. Maar deze aanpassingen moeten dan ook weer in de eerste testomgeving aangepast worden.

Na een lang verhaal eindelijk de vraag: Hoe gaan jullie hiermee om? Hoe kunnen wij dit oplossen dat we geen versie problemen meer hebben. Ik ben wel eens bezig geweest met svn maar zou niet weten hoe ik dit zou moeten implementeren.

[DaRKie]

1 simpel antwoord: cvs/svn en dan met versies en branches werken

[x-force]

Okey een antwoord in die richting had ik verwacht. Maar hoe zit het dan met branches?
Je begint met een hoofd reposetory. Daarna maak je een branche voor elke 'haast klus'? En hoe kan je dan functionaliteit live zetten? Maak je daarvoor een branche of exporteer je dan een branche/reposetory?

[momania]

Je versies sla je op in svn in de 'tags' lijn.

Je werkt verder altijd verdert op de hoofdlijn (de 'trunk')

Mocht je een wijziging moeten doen op een bestaande versie, dan kan je een kopie van een 'tag' pakken en daar een branch van maken. Wijzigingen doen en dan de branch deployen.

Die branch kan je dan na deployment weer opslaan in je 'tags' lijn en gaan mergen met je trunk.

Dus in svn heb je zeg maar in je repository 3 hoofd directories:

- tags -> backups van gedeployde versies
- branches -> aftakkingen voor parrallele wijzigingen
- trunk -> hoofd ontwikkel versie



[edit]
Voor beheer van je svn kan je bv TortoiseSVN gebruiken

[ Voor 10% gewijzigd door momania op 07-06-2007 11:36 ]

[Janoz]

x-force schreef op donderdag 07 juni 2007 @ 11:27:
Okey een antwoord in die richting had ik verwacht. Maar hoe zit het dan met branches?
Je begint met een hoofd reposetory. Daarna maak je een branche voor elke 'haast klus'? En hoe kan je dan functionaliteit live zetten? Maak je daarvoor een branche of exporteer je dan een branche/reposetory?

Over het algemeen is ene haastklus iets dat gebeurt op hetgeen op dat moment live staat. Na de haastklus is die versie degene die online staat. Eigenlijk heb je in jullie geval dus eigenlijk maar 2 branches waar actief aan gewerkt wordt.

Hoe je daadwerkelijk alles aanpakt is afhankelijk van de gekoze strategie. Er zijn namelijk verschillende manieren om het aan te pakken die elk zijn voor en nadeel en zijn voor en tegenstanders heeft.

Wat ik in jullie geval aanraad is om gewoon in de trunk(svn) of head(cvs) te gaan werken met de nieuwe ontwikkelingen. Zodra je klaar bent en de boel live wilt gaan zetten branch je dit af met als naam een versie nummer (staat ook leuk dat je op dat moment versie x online hebt staan ). Mochten er dan tijdens het ontwikkelen van de volgende versies spoedklussen binnen komen, dan check je de branch van de vorige versie uit en ga je daar op aan het werk. Let er op dat je, voordat je de nieuwe versie op gaat leveren, je nog wel even de vorige versie naar de nieuwe versie toe merged. Op die manier komen de aanpassingen van de spoedklus ook in de nieuwe versie terecht.

Ik wil je nog wel even de volgende tips meegeven:
- Zet nu gewoon even een repository op (cvs of svn) en ga er gewoon mee kloten. Vraag ook je projectgenoten om er flink in om te stampen. Maak een klein projectje met een paar pagina's en probeer eens wat te branchen en mergen. Pas een bestand aan met z'n tweeen tegelijk en kijk hoe je conflicten aan moet pakken... Kortom, lekker in de zandbak spelen. Omdat het een dummy project is maakt het niet zoveel uit als er van alles mis gaat, maar je mertk we waar eventuele knelpunten zitten en je kunt een beetje oefenen met werkwijzes.

-Voeg naast productie en test ook een acceptatie omgeving toe (Hoeft geen apparte server te zijn, gewoon een extra website op de test bak oid). Deployen naar de acceptatie omgeving doe je ALTIJD rechtstreeks uit je repository. Acceptatie gebruik je om (al dan niet met de klant) nog even te kijken of alles klopt. Doordat je dit rechtstreeks uit je repository haalt kun je daar ook problemen mbt het niet ingechecked maar wel op test gezette code achterhalen. Als alles in orde is zet je de boel op productie. Ook hier geldt weer dat je alles uit je repository haalt. Pas nooit dingen rechtstreeks aan op acceptatie en productie. Dat is misschien wel ff makkelijk en snel, maar dat zijn typisch van die dingen die je vervolgens vergeet aan te passen op de plekken waar het hoort.

[The - DDD]

Veel plezier:
http://svnbook.red-bean.com/

Gewoon een kwestie van een beetje proberen en je hebt het zo in de vingers. Lees vooral het stuk over branchen en mergen goed door. Daar zitten wat valkuilen in bij subversion.

[alienfruit]

Ik gebruik zelf een handig hulpmiddel hiervoor: http://software.pmade.com/svnauto

[sopsop]

De (iig voor mij en een hoop bedrijven) is een omgeving waarin je minimaal drie omgevingen hebt. Eigenlijk zouden het er vier moeten zijn.

1. Ontwikkelomgeving
2. Testomgeving
3. Acceptatieomgeving*
4. Productieomgeving

Hierbij zou de derde omgeving samen met de testomgeving kunnen samengaan. Het is echter handiger om (zeker wanneer er sprake is van een database/dynamische omgeving) om de testomgeving te voorzien van testdata en de acceptatieomgeving een technische kopie van de productieomgeving te laten zijn.

[x-force]

De drie omgevingen gaan we opzetten, dat waren we al van plan. Ik ben bezig om svn te installeren en te gaan gebruiken. Het ziet er veel belovend uit! We zullen alleen wel flink de manier van werken moeten aanpassen. Met dat inchecken en outchecken.

Maar ik ga het testen!

[ColdSTone|IA]

SVN is geen check-in/out systeem maar een merge-commit systeem:
- Gebruiker A doet een wijziging en commit deze, er is geen probleem, wijzigingen worden doorgevoerd.
- Gebruiker B voert nu een wijziging door t.o.v. de file van voor de commit van A. Nu is er wel een "probleem". De wijzigingen van B moeten namelijk samengevoegd worden met die van A. Op het moment dat B wil committen krijgt hij een melding, dan moet je eerst ff updaten en worden de nieuwe versie van A en de nieuwe versie van B ge-merged. Dit gaat in veel gevallen automatisch, soms zijn er echter problemen en dient de gebruiker zelf naar de file te kijken. Als allen problemen opgelost zijn kan de nieuwe file opnieuw gecommit worden en zijn alle wijzigingen doorgevoerd.

[Soultaker]

Hoewel Subversion op zich wel fijn is (al weet ik niet of het ideaal is voor webdevelopment), is het hier niet nodig. Mag natuurlijk wel, maar je kunt beter eerst de kern van je probleem identificeren en dán een oplossing daarbij kiezen. Subversion is een hulpmiddel, geen doel op zich.

Ik denk dat het veel beter zou zijn om gewoon twéé testomgevingen bijhouden: eentje die correspondeert met de live-versie (A), en eentje waaraan ontwikkeld wordt (B). Als je een nieuwe versie hebt gemaakt, zet je B online, en kopieer je bovendien B naar A. (Oude live-versie wil je waarschijnlijk eerst back-uppen.) Het is duidelijk dat je dan wijzigingen in de live-versie lokaal kunt ontwikkelen en testen, zonder gedwongen te zijn de ontwikkelversie te stabiliseren en online te zetten.

Dit heeft nog twee voordelen, namelijk het mergen van gegevens in een database. Bijna alle websites die ik ontwikkel werken met een database, en hebben behalve front-end data (bijvoorbeeld reacties of bestellingen) administratieve back-ends waardoor allerlei aspecten van de website in de live-versie aangepast kunnen worden door de klant. Als je een lokale kopie hebt van de live-versie met relevante data, kun je ook makkelijk lokaal kijken hoe je de database tussen twee versies moet upgraden. Bovendien kun je versie A met de live-versie vergelijken om te zien wat er veranderd is, wat ook erg nuttig is om problemen te kunnen diagnosticeren.

Subversion gebruiken voor webdesign is m.i. verder vooral zinnig als je ook een plan hebt om databasedumps in je revisies op te nemen. Ik weet niet of dat handig te doen is. Alleen je code in Subversion stoppen helpt wel (zeker als light-weight back-up systeem) maar lost naar mijn idee niet al je versie-problemen op.

[dingstje]

Soultaker schreef op vrijdag 08 juni 2007 @ 15:48:Ik denk dat het veel beter zou zijn om gewoon twéé testomgevingen bijhouden: eentje die correspondeert met de live-versie (A), en eentje waaraan ontwikkeld wordt (B). Als je een nieuwe versie hebt gemaakt, zet je B online, en kopieer je bovendien B naar A. (Oude live-versie wil je waarschijnlijk eerst back-uppen.) Het is duidelijk dat je dan wijzigingen in de live-versie lokaal kunt ontwikkelen en testen, zonder gedwongen te zijn de ontwikkelversie te stabiliseren en online te zetten.

Maar dan moet je nog altijd de livechanges in A terug manueel gaan mergen met B, wat een error prone proces is. SVN regelt daar heel wat voor je, waardoor het m.i. een beter middel is dan werken met twee 'mappen' A en B.

[drm]

In tegenstelling tot wat Janoz oppert, gebruiken wij (ik en mij collega's) de HEAD branche voornamelijk als versie die "stable" moet zijn. In wat voor project dan ook, in principe moet de HEAD altijd online gezet kunnen worden zonder dat dat gevolgen heeft voor de beschikbare functionaliteit. Nieuwe dingen worden dus in branches ontwikkeld. Als er "spoedklussen" zijn, wordt daarvoor juist direct in de HEAD gewerkt, want als je als regel aanhoudt dat dat de versie is die zonder meer online gezet kan worden, is dat dus juist nodig.

Voordat je dus de HEAD met een ontwikkelbranche merged, doe je eerst het tegenovergestelde en test je alles wat getest moet worden. Daarna doe je hetzelfde nogmaals vice versa, (je merged de ontwikkelbranch de HEAD in) en dan test je het nogmaals door. Dan is de update doorgevoerd en kan je eventueel nog gaan taggen. Dat is dan minder nuttig geworden, vanwege het feit dat het toch stable is.

Voor databases moet je gewoon altijd updatescripts maken, en niet alleen met dumps werken. Het makkelijkst is om zoveel mogelijk gewoon met SQL te doen, en dat in een updates.sql bestand ofzo op te slaan, dat je per versie ook precies kunt zien wat dan de updates in sql geweest zijn. Voordat je zaken online gaat zetten dus de online database dumpen, op de testserver inlezen, update script uitvoeren en dan testen.

En domweg changelogs schrijven.

Anyhow, ik raad iedereen een versiebeheersysteem aan. Hoe klein ook, het is altijd een lekker idee dat je makkelijk terug kan naar "wat je gister aan 't klooien was"

[x-force]

Het zal waarschijnlijk iets worden wat drm zegt gecombineerd met de drie omgevingen. Ik zit alleen nog met een ander probleem. Bij software schrijven heeft iedereen lokaal zijn eigen kopie en kan de applicatie draaien.

Bij ons (en bij websites algemeen) is dit meestal niet het geval. Wanneer iemand een file uit checked staat hij lokaal. Dan zal ik aanpassingen maken en uploaden naar de ontwikkel omgeving. Daar test ik en verander ik verder. Waneer het af is check ik de files weer in. Maar volgens mij kunnen we dus niet met meerdere mensen op 1 server / 1 map werken. Want elke gebruik kan met een andere versie werken (toch?).

Dus dan zal je iets moeten maken dat elke gebruiker een eigen ontwikkel map krijg. Voor de database zie ik geen problemen dus ik denk dat die wel gedeeld kan worden. (Er zullen niet meerdere mensen tegelijk aan het database ontwerp werken).

Zie ik dit nu goed of zijn hier andere oplossingen voor?

edit:
typo

[drm]

Wat wij doen is een gepersonaliseerde testomgeving. Wij hebben op de ontwikkelserver een hostname die als documentroot de homedir van de betreffende gebruiker heeft. De bestanden waar je in werkt staan in die homedir. Dat werkt alleen echt goed als je de testserver lokaal hebt staan, maar dat is wederom een aanrader.

edit:

Vergeet ik nog te melden dat je de betreffende hostname gewoon in je hosts-file zet zodat 'ie naar de testserver verwijst.

[ Voor 18% gewijzigd door drm op 09-06-2007 01:55 ]

[Verwijderd]

even inpikken op dit met onze situatie.

We zitten hier met onze studentenvereniging met een website waar heel wat mensen hun
stekje op hebben. Elke "post" heeft een login op een soort van testsysteem. Ze dienen alles
te zetten (hun php html files etc) in een \wwwtest\post directory waar ze dus alles op kunnen zetten.
vervolgens gaan ze naar een link waar ze op klikken die dan zorgt voor het overkopieren van de bestanden die gewijzigd zijn naar de \www\post wat dan de live omgeving is. Maar het probleem is nu wanneer we werken met file-uploads vanop de website dan komt dit enkel terecht in de \www directory wat dus uiteindelijk problemen geeft dat wwwtest en www niet echt perfect gesynced zijn.
Ook databases zijn zo niet gesynced. Alles zou dus eigenlijk perfect "gemirrored" moeten worden?

Nu dit systeem zou dus volledig vernieuwd moeten worden, maar hoe doe je dit op een toch iets gebruiksvriendelijke manier. Wat we nu dus wensen te doen is dat men per directory zijn eigen deeltje van een website kan maken (toegang via winscp of zo), testen en dan overzetten naar liveomgeving.
Waarbij alles mooi gesynced blijft als er bijvoorbeeld uploads zijn van bestanden (foto's en zo. Wat inderdaad met databases? Hoe sync je die? Ik zie die mensen ook niet direct branchen
met svn en zo of is dit eenvoudig te scripten. Een mens kan soms wel een kleine website maken maar om direct in svn te beginnen is dat toch niet zo evident vermoed ik.

Wat hierbij dan ook handig is, is dat indien ze per ongeluk iets verkeerd gedaan hebben, het nog te herstellen is via een history van svn?

Als mensen hierover wat ideetjes hebben om ons in een iets meer concretere richting te sturen, wij zijn uw eeuwig dankbaar!