SVN gebruiken voor update productie server

[vorlox]

Beste Allemaal,

Ik zit met een probleem waar ik niet goed de juiste methode voor kan vinden.
Ik heb 2 servers bij een hosting bedrijf...een test server en een productie server.

Al mijn ontwikkelwerk doe ik op de test server.
De code van test gooi ik naar SVN.

Als ik wil deployen op productie gooi ik eerst mijn lokale FTP map van productie leeg en doe ik daar een nieuwe export. Dit doe ik omdat ik geen .svn bestanden wil uploaden naar de server.
Daarna FTP ik alles naar de server.

Nu weet ik dus nooit welke code er eigenlijk wijzigd op de productie server.
Meer dan FTP toegang heb ik op deze server niet..

Is dit nu echt de enige manier of iemand een beter idee.

[RobIII]

vorlox schreef op maandag 26 december 2011 @ 20:34:
Meer dan FTP toegang heb ik op deze server niet..

Is dit nu echt de enige manier of iemand een beter idee.

Je beantwoordt net je eigen vraag lijkt me. Als je enkel en alleen FTP toegang hebt wat verwacht je dan?
Je kunt 4 dingen doen die ik zo snel verzonnen krijg; geen van alle echt spannend:

1) De .svn files voor lief nemen (ik gebruik geen svn maar een ander VCS dus geen idee wat er in die files staat maar 't lijkt me weinig interessant¹); eventueel scherm je .svn files nog af met je .htaccess
2) De methode die je nu gebruikt blijven hanteren
3) Andere VCS gebruiken die geen files in je directories aanlegt; lijkt me nogal wat rigoreus
4) Eén of ander script bouwen dat op de webserver een export doet en daarna de meuk opruimt; dan ga ik er wel van uit dat je PHP of een andere scriptingtaal kunt gebruiken op je hosting.

¹ Klaarblijkelijk kan 't wél gegevens bevatten die je niet op straat wil hebben liggen...

[ Voor 17% gewijzigd door RobIII op 26-12-2011 21:57 ]

[vorlox]

1) Neh...liever geen SVN bestanden op PRD
2) Tja dat doe ik dus.
3) Zit ik dan niet met een soortgelijk probleem
4 )Redelijk gevaarlijk

5) Dus toch maar de hoster lief aankijken en vragen of hij mij shell access verschaft en SVN installeert indien niet al aanwezig.

[RobIII]

vorlox schreef op maandag 26 december 2011 @ 21:56:
1) Neh...liever geen SVN bestanden op PRD

Again; als ze er al zouden staan (en je dus optie 1 zou verkiezen) zou je ze evt. kunnen afschermen met een .htaccess ofzo. Mooi is anders, maar als je aangeeft gelimiteerd te zijn in je opties en de huidige werkmethode te omslachtig vindt moet je creatief worden niet?

vorlox schreef op maandag 26 december 2011 @ 21:56:
3) Zit ik dan niet met een soortgelijk probleem

Nogal afhankelijk van welke VCS je gebruikt he?

vorlox schreef op maandag 26 december 2011 @ 21:56:
4 )Redelijk gevaarlijk

Ja, nee, ja... misschien. Wat jij gevaarlijk vindt. Zet 't achter een wachtwoord en 't is net zo "safe" als je FTP account (die overigens vaker op straat komen te liggen omdat je FTP client (Filezilla is hier notoir in (geweest?)) wachtwoorden plain-text opslaat die vervolgens door een random virus naar z'n maker worden gestuurd).

vorlox schreef op maandag 26 december 2011 @ 21:56:
5) Dus toch maar de hoster lief aankijken en vragen of hij mij shell access verschaft en SVN installeert indien niet al aanwezig.

Dan is er dus wél meer mogelijk dan je in je TS aangeeft; dat is dan IMHO ook een optie die je 't eerst had moeten proberen.

edit:

En wat smesjz hieronder zegt inderdaad: waarom zou 't überhaupt interessant zijn te weten wat er gaat wijzigen?

[ Voor 20% gewijzigd door RobIII op 26-12-2011 22:04 ]

[smesjz]

Nu weet ik dus nooit welke code er eigenlijk wijzigd op de productie server.

Dat is toch niet interessant?

Je weet toch welke code er gaat wijzigen (diff van huidige versie op productie t.o.v. versie die je wil gaan pushen)?

Als je SSH toegang krijgt zou ik gewoon kiezen voor synchronisatie middels rsync. Dus lokaal export maken van de versie die je wil pushen en vanaf daar rsyncen naar je host.

[Super_ik]

gebruik je wel tags? Als je elke versie die je op de server zet tagged, dan kun je makkelijk een svn log opvragen tussen 2 tags.

[orf]

Wij hebben een publisher. Die upload bij een complete export alles naar productie. Daarnaast uploaden we automatisch een .rev bestand mee met daarin het revisienummer. Als de publisher een .rev bestand in de root ziet, dan wordt er gewoon een diff gedaan tussen de revisie die op de productie staat en de revisie die je wilt uploaden. Vanaf daar worden alleen de gewijzigde bestanden geüpload en bestanden die verwijderd moeten worden verwijderd. Daarnaast legen we altijd de temp mappen waarin bij ons gegenereerde files staan.

Wij gebruiken daar Phing voor en gewoon PHP scripts die de FTP uploads doen.

[SysRq]

vorlox schreef op maandag 26 december 2011 @ 20:34:
Nu weet ik dus nooit welke code er eigenlijk wijzigt op de productie server.

TAGS!

Oftewel, voor de export een tag aanmaken in svn. Daarna kun je heel makkelijk een diff doen.

vorlox schreef op maandag 26 december 2011 @ 21:56:
5) Dus toch maar de hoster lief aankijken en vragen of hij mij shell access verschaft en SVN installeert indien niet al aanwezig.

?? Dan krijg je toch gewoon weer .svn bestanden op de productieserver?

[ Voor 31% gewijzigd door SysRq op 27-12-2011 00:20 ]

[alwinuzz]

Je kan een batch of powershell script maken die:
1) tag maakt
2) svn export
3) upload naar server

of:

1) tag maakt
2) svn diff tussen deze en vorige tag
3) upload veranderde bestanden naar server

Dus je handmatige stappen automatiseren en versimpelen naar één muisklik.
Eventueel met waarschuwing "WEET JE HET ZEKER? Y/N"

[ZaZ]

Misschien begrijp ik het niet helemaal, maar waarom zou er code zomaar wijzigen op de productieserver?
Dat moet dan toch eerst via versiebeheer zijn gegaan of zitten er mensen rechtstreeks in de productiecode te klooien?
Versiebeheer is een enorme verrijking mits je het wel volgens de regeltjes speelt.

[Hydra]

SysRq schreef op dinsdag 27 december 2011 @ 00:20:
[...]

TAGS!

Oftewel, voor de export een tag aanmaken in svn. Daarna kun je heel makkelijk een diff doen.

Dat. Daarnaast kun je met wat commandline tools heel simpel de hele bubs naar je productie server uploaden. Ik gebruik voor simpele zaken vaak gewoon ant scripts. Ant heeft ook een FTP task.

[xzaz]

ZaZ schreef op woensdag 28 december 2011 @ 13:10:
Misschien begrijp ik het niet helemaal, maar waarom zou er code zomaar wijzigen op de productieserver?
Dat moet dan toch eerst via versiebeheer zijn gegaan of zitten er mensen rechtstreeks in de productiecode te klooien?
Versiebeheer is een enorme verrijking mits je het wel volgens de regeltjes speelt.

Ik zie het probleem ook niet. Je houdt netjes bij in je release note welke revs van welke bestanden je gebruikte. Dat maakt een release > versie.
De productie server heeft dus geen idee van revs maar alleen van versie.

Als je dan een nieuwe release doet hebben deze onderdelen nieuwe revs. In de release note kan je dan kijken wat er veranderd is.

Zoek eens wat informatie over ASL oid.

[Herko_ter_Horst]

xzaz schreef op zondag 01 januari 2012 @ 14:38:
[...]
Ik zie het probleem ook niet. Je houdt netjes bij in je release note welke revs van welke bestanden je gebruikte.

Als je zelf tags/branches opnieuw wilt gaan uitvinden, moet je het zo doen, ja...

Gewoon een tag zetten (of een branch starten als je onafhankelijk van de trunk zaken wilt kunnen bouwen/fixen).

Op de zaak gebruiken we momenteel twee verschillende methodes (voor verschillende projecten uiteraard, niet binnen één project):

- alle ontwikkeling in een branch, merge naar de trunk bij release
- alle ontwikkeling in de trunk, nieuwe branch bij release

Tags worden bij ons gebruikt voor niet-publieke releases (sprint-oplevering, milestones, demo-versies, etc).

Vanuit een branch (of een tag) kunnen we op elk moment een release maken.


Andere tip: automatiseer alle acties die je moet doen voor een release.

[ Voor 8% gewijzigd door Herko_ter_Horst op 01-01-2012 22:32 ]