Używanie SVN z witryną pośredniczącą i na żywo

Question

Mam obecnie repozytorium svn na moim hostowanym serwerze internetowym. Pracuję lokalnie, zatwierdzam moje zmiany w repozytorium na moim serwerze, a następnie uruchamiam "aktualizację svn" przez ssh w moim folderze na żywo, kiedy jestem gotowy, aby wprowadzić zmiany na żywo.

Dodaję teraz witrynę przemieszczania, która będzie znajdować się na tym samym serwerze. Będzie to po prostu kolejny folder na tym samym serwerze.

Problem polega na tym, że będę pracował nad nieco większymi zmianami w witrynie na serwerze pomostowym, które mogą zająć nawet tydzień testów. W tym czasie mogę chcieć dokonać drobnej kosmetycznej zmiany w witrynie na żywo, która nie wymaga testów. Weźmy przykład:

1. Załóżmy mój lokalny, inscenizację i witrynę, wszystko zaczęło się na rewizji 1.
2. dokonać poważnych zmian lokalnie, zobowiązać je i zaktualizować serwera pomostowego. Lokalna i inscenizacja są w wersji 2, na żywo jest nadal 1.
3. Ktoś prosi o prostą zmianę tekstu na stronie na żywo.
4. Ugh. Teraz muszę przywrócić kopię lokalną do wersji 1, wprowadzić małą zmianę i zatwierdzić ją. Teraz aktualizuję witrynę na żywo do wersji 3, która ma niewielką zmianę.
5. Chcę dalej pracować nad moimi dużymi zmianami, więc aktualizuję lokalną kopię do wersji 2 i dalej pracuję.
6. I tak dalej ....

Zmusza mnie śledzić revsions i stale być aktualizowanie i powrotu. Czy istnieje lepszy sposób? Czuję, że mam tu używać rozgałęzień i tagów, ale nie rozumiem, jak dokładnie.

Dzięki Jonasz

Answer 1

Zarządzam sklepem deweloperskim złożonym z 5 deweloperów. Używamy SVN w następujący sposób na naszej stronie internetowej:

• Deweloperzy zatwierdzają wszystkie ulepszenia lub poprawki błędów w naszej gałęzi "dev", zanim uznają pracę za zakończoną.
• Zadania są testowane na skrzynce pomostowej z najnowszym kodem w gałęzi dev.
• Po przejściu testu testowego, poprawki do tego zadania są scalane z naszym odgałęzieniem.
• Nasze serwery internetowe na żywo uruchamiają gałąź bagażnika. Okresowo są one aktualizowane za pomocą skryptu "publikuj", który aktualizuje SVN na serwerach na żywo i wykonuje także inne czynności (takie jak zaciemnianie i minimalizowanie CSS i JavaScript).

Pozwala to na małe błędy, aby przedostać się przez rurociąg w sposób szybki i większy, aby poświęcić tyle czasu, ile potrzeba na rozwój i testowanie.

Ponieważ każdy programista odpowiada za scalanie własnych zadań, a każde scalenie składa się z mniejszego zestawu zmian kodu, działają one całkiem sprawnie. Jest o wiele mniej gorączkowy niż starszy wzorzec posiadania menedżera łączenia, stanowiącego istotną gałąź ulepszeń dla zestawu ulepszeń. Ponieważ inni deweloperzy zazwyczaj pracują razem nad zestawem ulepszeń, otrzymasz menedżera korespondencji seryjnej, który połączy kod, którego nie napisał, co staje się szczególnie frustrujące, gdy masz konflikty scalania.

W rzeczywistości ta metoda odzwierciedla metody, jakimi systemy kontroli wersji, takie jak Git i Mercurial, starają się promować, budując swoje repozytoria. W przypadku tych systemów wersjonowania każdy programista ma swoje "lokalne" repozytorium. Kiedy chcą zmiany z innego "repozytorium", muszą scalić je z lokalnym kodem, a następnie zatwierdzić poprawną wersję "scaloną".

Możesz także użyć tagowania, o którym wspomniał Andy w swojej odpowiedzi na to pytanie. To może działać dla ciebie, ale wolę ponosić odpowiedzialność za łączenie się z programistami, którzy piszą kod, a nie centralnym deweloperem lub menedżerem publikacji. W ten sposób idą gładko.

Answer 2

Jak już zidentyfikować najlepszy sposób, aby to zrobić jest użycie rozgałęzienia i tagowania. Dobrym przykładem tego jest:

Główne rozwój

1. Robisz swój znaczący rozwój na pniu.
2. Za każdym razem, gdy wydajesz kopię swojego oprogramowania do życia, tworzysz znacznik z pnia i zmieniasz stronę, by wskazywała na nowy tag.

Kiedy trzeba dokonać małej zmiany do żyjesz może teraz wykonać następujące czynności:

1. Utwórz gałąź z tagiem na żywo, a do pracy tutaj.
2. Po uzyskaniu zadowolenia z tej zmiany należy utworzyć nowy znacznik z tej gałęzi i zmienić kopię roboczą na żywo na nowy.
3. Można również scalić tę zmianę z gałęzi do pnia, aby ta zmiana była również w następnej ważnej wersji.

Jest naprawdę dobra książka opłata na dywersji, która wyjaśnia wszystko to w rozdzierający szczegółów tutaj:

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

Jeśli znajdziesz czas bym zdecydowanie wskazują odczytu.