Migratie van StarTeam naar gedistribueerde bronbesturing

We gebruiken momenteel StarTeam voor ons project en de licentie verloopt binnenkort. We kijken naar overstap naar Team Foundation Server of iets dergelijks, maar er is een push (meestal van mezelf en een andere persoon) om over te schakelen naar een vorm van gedistribueerd versiebeheer. Een van de problemen is dat onze verandermanager de wijzigingsaanvraag (zoals in StarTeam) wil kunnen volgen en vrijgeven, en ik geloof niet dat dit gemakkelijk kan worden gedaan met Mercurial of Git out-of-the-box (alstublieft verbeter mij als ik het fout heb).

Dit is een 15 jaar oud product met duizenden Java-bestanden en PL/SQL-pakketten, onderhouden door 5-6 ontwikkelingstitels met in totaal 30-40 ontwikkelaars. Voor mij lijkt het erop dat een gedistribueerde repository een nachtmerrie zou worden met de "commit early, commit often" mindset. Het feit dat elk team zou werken aan een volledig ander subsysteem in dezelfde repository maakt het nog gemener in mijn gedachten.

Ons huidige StarTeam-proces voor elke verandering is als zodanig:

  1. Vergrendel het bestand (en) waarmee u wilt werken,
  2. Voer uw volledige wijziging uit en laat deze controleren op basis van een kopie op een netwerkstation
  3. Check in (en ontgrendel) de gewijzigde bestanden, in de hoop dat iemand je slot niet met geweld heeft verbroken,
  4. Ik hoop dat uw wijziging de build niet heeft verbroken van de wijziging van iemand anders naar andere bestanden

Persoonlijk vind ik het idee om bestanden te "vergrendelen" belachelijk. Er moet voldoende communicatie tussen teams zijn, zodat u dat niet hoeft te doen.

Heeft iemand hier ervaring met gedistribueerde opslagplaatsen op projecten van vergelijkbare omvang? Kunt u suggesties doen voor oplossingen voor versiebeheer en/of wijzigingsbeheer? De belangrijkste vereiste is dat het systeem door de klant geïnitieerde wijzigingsverzoeken kan beheren en ontwikkelaars dwingen hun checkins aan één te koppelen.

Bedankt.

5

6 antwoord

We hebben dit met veel succes met git gedaan. We volgen dit proces. Zeer eenvoudig om de voortgang van elk probleem te volgen:

https://plus.google.com/109096274754593704906/posts/R4qkeyRadLR

Als je naar de opmerkingen kijkt, zijn er enkele invloedrijke mensen geweest die het proces hebben bekeken. Het is een geweldige manier om te werken en hopelijk zal dat schrijven je de munitie geven die je nodig hebt. Voor specifieke TFS-zaken, kijk hier:

TFS branching, what are the advantages (misleading title)

4
toegevoegd

Zowel Git als Mercurial worden gebruikt voor projecten met een complexiteit die veel groter is dan wat je hebt genoemd. Dus het gebruik van Git/Mercurial voor de grootte van uw projectteam mag geen probleem zijn.

Van nature willen we meer controle over de versiebeheerserver. Subversion is daarom erg populair.

Het is altijd gemakkelijk om releases te behouden op basis van wijzigingen die zijn ingesteld met DVCS zoals Mercurial of Git.

U kunt een reposito instellen waar wijzigingssets alleen na beoordeling worden gepusht. Dit zou de vereisten van uw change manager moeten verminderen.

DVCS heeft als voordeel dat je gemakkelijk experimentele takken of klonen kunt maken, ze kunt weggooien als het niet werkt en de veranderingen naar binnen kunt halen als je denkt dat ze klaar zijn voor primetime. Vaak vastleggen/vroeg vastleggen is een praktijk die goed werkt met DVCS omdat u wijzigingen in uw eigen repo pusht. Zodra het is gebakken, kunt u het naar boven duwen voor beschikbaarheid binnen het team.

Het vergrendelen van bestanden is een oud tijdperk. Het wordt zelfs niet gebruikt door tools zoals Subversion. Het is echt een belemmering om te werken.

4
toegevoegd

Git biedt niet het "change management" -proces dat u zoekt. Dit is een van die beheersvereisten die commerciële versiecontrolesystemen graag adverteren om bedrijven aan te trekken met glimmende objecten. Dat betekent niet dat je het niet kunt doen, het is net buiten het domein van Git's doel. Net zoals authenticatie en toegangscontrole (je kunt ssh en gitolite gebruiken, maar git zelf biedt deze services niet). U zult deze integratie waarschijnlijk zelf moeten ontwikkelen, tenzij u werkt met een veelvoorkomende bug-tracking tool.

Bestanden vergrendelen is altijd fout. Dit is waar "samenvoegen" voor is.

Ik werk momenteel aan een codebase van ~ 200.000 regels code met 10 ontwikkelaars en git werkt erg goed. We hebben groepen van een grotere orde, ook met behulp van git op andere projecten. Git's kracht ligt in fuseren en dit is hoe het omgaat met meerdere ontwikkelaars en veel commits. Houd in gedachten dat elke push een samenvoeging is in git, of het er nu naar uitziet of niet. Uw lokale repository heeft mogelijk een vertakking met de naam master , maar het is niet dezelfde vertakking als master in de centrale repository. Om ze te synchroniseren, maak je een samenvoeging, wat soms gewoon een "fast-forward merge" is.

We doen niet de moeite om een ​​sterke link te forceren om verzoeken te wijzigen. Toen ik overwoog een interface te schrijven om dit te doen, was een probleem dat ik tegenkwam hoe je het domme volgsysteem bewust kunt maken van elke tak waarin een insect zit. Een simpele haak is hiervoor niet voldoende.

Je moet verhuizen naar git voor verbetering van het ontwikkelingsproces. Voor mij is het fundamenteel veranderd (verbeterd) op de manier waarop ik code schrijf. U wordt uitgedaagd om een ​​pleidooi te houden voor het beter afhandelen van verandermanagement in zakelijke taal zonder alle voorverpakte kogels die afkomstig zijn van dure IBM-tools. Het echte probleem is dat als je eenmaal Git omarmt, je nooit meer met een van de andere tools kunt werken, ongeacht hoe goed een businesscase die ze presenteren ...

3
toegevoegd
Heel goed gezegd! Ik werk met Mercurial en als ik met klanten praat, vragen ze vaak om "wijzigingsverzoeken". Als ik hen vertel dat Mercurial niet zo'n idee had, werden ze verrast. Net als Git is Mercurial een gericht hulpmiddel. Het doet versiebeheer en laat je workflows bovenaan definiëren. U kunt de workflows in termen van wijzigingsverzoeken uitdrukken als u dat wilt, maar dat hoeft niet.
toegevoegd de auteur Martin Geisler, de bron
@Samah Dit hangt echt af van het ontwikkelingsmodel dat je volgt. Ik raad ten zeerste aan dat als je git overweegt, je overweegt je proces aan te passen om te profiteren van de functies (zoals goedkope vertakking, logische commits). Voor releases van bugfixes maken we bijvoorbeeld een nieuwe releasetak wanneer we een release plannen. De wijzigingen worden samengevoegd of kers in deze tak geplukt door de releaselood uit verschillende bronnen (dev branches, topic branches). Als we van gedachten veranderen, kan hij een opdracht uitvoeren om de commit terug te draaien of te rebasen en de wijziging weg te vegen.
toegevoegd de auteur djs, de bron
Hoe zou je omgaan met het geval dat (bijvoorbeeld) 20 wijzigingsverzoeken gepland zijn voor productie, maar op het laatste moment is besloten dat er een moet worden getrokken? Van wat ik kan zien, zou je moeten terugkeren naar de revisie voor die fusie, en dan eventuele zaken die na de fusie zijn ontstaan, samenvoegen. Dat lijkt veel moeite. Met ons huidige systeem geven we gewoon niet de bestanden vrij die betrekking hebben op die CR (ervan uitgaande dat ze geen deel uitmaakten van een andere CR).
toegevoegd de auteur Samah, de bron

Ik schreef dit in een opmerking, maar ik denk dat het belangrijk genoeg is dat het een volledig antwoord verdient.

Ik werk als Mercurial-consultant en als ik met klanten praat, vragen ze vaak om "wijzigingsverzoeken" en "wijzigingsbeheer". Als ik hen vertel dat Mercurial niet zo'n idee had, worden ze verrast. Net als Git is Mercurial een gerichte tool. Het doet versiebeheer en laat je workflows bovenaan definiëren. U kunt de workflows in termen van wijzigingsverzoeken uitdrukken als u dat wilt, maar dat hoeft niet.

De gebruikelijke manier om wijzigingsverzoeken te behandelen, is ze in een of andere soort probleemendossier te plaatsen. Het koppelen van de changesets met een CR kan worden gedaan met benoemde filialen in Mercurial of met behulp van opmerkingen in de commit-berichten in Git. Wanneer het probleem naar een centrale server wordt doorgestuurd, wordt het probleem door een haak bijgewerkt.

U noemt het omgaan met veranderingen die toch geen onderdeel van een release zouden moeten zijn. De gemakkelijkste manier is om niet samen te voegen met de hoofdlijn voordat bekend is dat de wijziging stabiel is. Je wilt nog steeds testen op de branch uitvoeren, dus je hebt een testopstelling nodig waarin je elke branch een voor een kunt testen. Om de afhankelijkheden tussen branches te testen, voeg je ze tentatief samen en voer je je tests uit op het resultaat. Je kunt doorgaan met werken aan de takken en de daaropvolgende fusies zullen klein zijn.

Ten slotte, wanneer je jezelf wilt committeren aan het vrijgeven van de branch, dan voeg je het samen in de hoofdlijn.

2
toegevoegd

Er is momenteel een git remote helper voor StarTeam die ook kan worden gebruikt om de geschiedenis van StarTeam in een git-repository te importeren die als vervanging voor StarTeam kan dienen.

De code staat op https://github.com/warrenfalk/git-st/tree/st_to_git_migration_features (het is een vork van git-st met een feature branch die in staat is om dit soort import te doen. De branch is st_to_git_migration_features.)

zie: https://github.com/warrenfalk/git-st /blob/st_to_git_migration_features/README.migration.md voor instructies over hoe dit te bereiken.

Ik heb dit gebruikt om de geschiedenis van StarTeam met succes in een git-repository te importeren.

1
toegevoegd

Het volgende is een kleine webtoepassing die projecten van StarTeam naar GIT-repository converteert.

http://dl.dropbox.com/u/101447754/startgit.tar.gz

Ik ontwikkelde omdat in mijn werk besloot te migreren en de mogelijkheid te geven dat elke groep zonder voorafgaand onderzoek zou werken om een ​​dergelijk proces te maken.

Nu:

StartGIT es una sencilla herramienta para trabajar con Controladores de Versiones, su fin es poder convertor un repositorio en Starteam a GIT, para ello se hace uso del script "svnimporter-1.2-st" obtenido en "http://www.polarion.com /user/direct_register.php?dl=svnimporterst ":

Tener instalado:   - GIT   - git-svn   - java   - apache2

Pasos:  - Descomprimir "startgit.zip"  - Colocar la carpeta descomprimida "startgit" en el directorio "/ var/www /"  - Abrir navegador web y colocar la siguiente direccción "http://localhost/startgit"

// ------------------------------------------------ -------------

StartGIT is een eenvoudige tool, het doel is om een ​​Starteam-repository naar GIT te converteren.

Dit script gebruikt de "svnimporter-1.2-st" verkregen "http://www.polarion.com/user/direct_register.php? Dl = svnimporterst"

Heb geïnstalleerd:    - GIT    - Git-svn    - java    - apache2

stappen:   - Unzip "startgit.zip"   - Plaats de uitgepakte map "startgit" in de "/ var/www /"   - Open een webbrowser en "http://localhost/startgit"

1
toegevoegd
Hallo Victor, ik wil graag contact met u opnemen over deze migratietool van StarTeam ... Hoe kan ik u vinden?
toegevoegd de auteur pablo, de bron
Hallo Victor, welkom bij StackOverflow.com. Gewoon een opmerking, je hoeft geen handtekening of persoonlijke informatie aan je berichten toe te voegen (antwoorden of vragen), je hebt al een profiel op je gebruikerspagina waar je die dingen kunt zetten. Proost
toegevoegd de auteur kolossus, de bron
Victor, heeft dit project een thuis op GitHub? Ik lees graag de README daar en kan mogelijk een bijdrage leveren.
toegevoegd de auteur Matt, de bron