W tej chwili używamy nieco skomplikowanej konfiguracji instalacji, która obejmuje zdalny serwer SVN, 3 gałęzie SVN dla DEV, STAGE i PROD, promując kod między nimi poprzez łatki itp. Zastanawiam się, czego używasz do wdrożenia w małym dev sytuacja zespołowa?Jaki jest twój ulubiony proces wdrażania aplikacji WWW z SVN?
Pień dla rozwoju i oddział (produkcja) do produkcji rzeczy.
Na moim komputerze lokalnym, mam VirtualHost, który wskazuje na gałąź bagażnika, aby przetestować moje zmiany.
Wszelkie zobowiązać się do pnia wyzwala hak commit, który robi wywóz svn i synchronizację do dev URL serwera internetowego - więc jeśli strona jest stackoverflow.com to ten hak automatycznie aktualizuje dev.stackoverflow.com
Potem użyj svnmerge, aby scalić wybrane łaty z pnia do produkcji w moich lokalnych kasach.Mam VirtualHost ponownie na mojej lokalnej maszynie, wskazując na gałąź produkcyjną.
Kiedy popełnić scalone zmian w branży produkcyjnej, ponownie hak eksport SVN aktualizuje produkcji (live) wywóz a strona jest na żywo!
Prosta gałąź bagażnika zawiera najbardziej aktualny kod, a następnie wycina gałąź, gdy tylko wejdziemy na rynek. Wydaje się, że działa całkiem skutecznie. Możesz łatwo przejść do poprzedniej gałęzi, gdy aktualna gałąź, którą wycinasz dla systemu na żywo, nie działa. Łatwo jest także naprawić błędy w gałęzi, która jest obecnie na żywo, a ponieważ gałąź skutecznie umiera, gdy wycinasz nową, istnieje tylko jedna prawdziwa gałąź, nad którą musisz popracować (a następnie scalić poprawki do żywy oddział).
Kiedy pracowałem w małym zespole deweloperskim (małe znaczenie dla mnie, innego programisty i szefa), był to chaotyczny bałagan. Okazało się jednak, że przydzielono nam proces przypisywania typu "gatekeeper".
Strażnik był osobą, która wykonała najwięcej pracy nad aplikacją (w tym przypadku miałem 2 projekty, które opracowałem od podstaw, miał 4).
Zasadniczo, gdy tylko pracował nad moimi projektami, powiadamiał mnie, że pracuje, upewniłem się, że repozytorium jest aktualne i możliwe do zbudowania, a następnie zrzuci, zrobi zmiany, a następnie zatwierdzenie. Poinformował mnie, że to się stało, chciałbym usunąć, zbudować i wdrożyć. Jeśli były zmiany DB, mieliśmy folder DB Change ze wszystkimi skryptami, które poprawiłyby DB.
Oczywiście ma w nim wiele dziur, ale proces zadziałał u nas i nie pozwalał nam budować się nawzajem.
Trzy gałęzie brzmią jak dodatkowa robota.
Różnice środowiskowe można rozwiązać, wyświetlając różne wersje odpowiednich plików w bagażniku. tj. database.yml & database.yml.prod. Proces wdrażania powinien być świadomy środowiska i po prostu skopiować pliki dotyczące poszczególnych środowisk w stosunku do domyślnych.
Nie używamy oddziałów do organizowania treści związanych z Internetem; tylko do testowania rzeczy eksperymentalnych, które zajmie dużo czasu (czytaj: więcej niż jeden dzień), aby połączyć się z powrotem do bagażnika. Pień w stylu "ciągłej integracji" reprezentuje (miejmy nadzieję) działający, aktualny stan.
W ten sposób większość zmian zostaje przekazana bezpośrednio do bagażnika. Serwer CruiseControl.NET automatycznie aktualizuje się na komputerze, na którym działa również IIS, i posiada aktualne kopie wszystkich dostępnych zasobów dodatkowej strony, dzięki czemu można w pełni przetestować tę stronę w domu. Po przetestowaniu pliki są przesyłane na serwer publiczny.
Nie powiedziałbym, że jest to idealne podejście, ale jest proste (a zatem odpowiednie dla naszych stosunkowo niewielkich pracowników) i stosunkowo bezpieczne i działa dobrze.
Używamy zwalniającą rozgałęzienia - to wydaje się być bardziej skuteczne niż dla nas funkcji rozgałęzień robiliśmy.
Nie należy tworzyć różnych gałęzi dla różnych środowisk.
Pień zawiera bieżącą "podstawową" bazę kodów rozwojowych.
Programista często tworzą indywidualny dla każdego oddziału średnio- i długoterminowego projektu, który mógłby wężem kodzie bagażnik i uzyskać na drodze do innych deweloperów. Kiedy skończy, wróci do bagażnika.
Tworzymy oznaczoną wersję za każdym razem, gdy przesyłamy kod do produkcji. Folder w/tags jest po prostu numerem wersji.
Aby wdrożyć do produkcji, robimy eksport SVN do przemieszczania. Kiedy to jest zadowalające, używamy prostego rsync do rozwinięcia w klastry produkcyjne.
osobiście działać lokalnie (rozwój), dodawanie/możliwości mocowania i kiedy myślę, że to gotowy oddaję do tułowia (produkcja). Na serwerze produkcyjnym po prostu wykonuję aktualizację svn.
Pracuję w sytuacji podobnej do obecnej. Miałem za zadanie znalezienie "lepszego" rozwiązania i uruchomiłem coś podobnego do następującego.
Aktywna gałąź przedstawia serwery w ich bieżącym stanie.
Wszelkie prace rozwojowe należy wykonywać w oddziale, który jest pobierany z sieci. Może to być jedna osoba, praca półgodzinna lub całoroczny projekt z wieloma zespołami. Tak często, jak wprowadzane zmiany na żywo można scalić w te gałęzie programistyczne.
Zanim utwór zostanie opublikowany, zmiany z transmisji na żywo zostaną ponownie połączone i zostaną oznaczone jako potencjalne wydanie To wydanie jest testowane w środowisku pomostowym i jeśli przejdzie testowanie, nowy plik zostanie pobrany z tagu.
Możliwe jest połączenie kilku kawałków pracy w jednym wydaniu, czy działa lepiej.
Oznacza to, że utrzymanie oddziałów rozwojowych jest na bieżąco z aktualizacją na żywo, a jeśli część prac rozwojowych zostanie usunięta, wystarczy wykonać minimalne czynności porządkowe.
Aby zmienić pracę z jednym projektem na inny, programista może po prostu zmienić swoje lokalne środowisko pracy na inny.
Jednym z problemów, które mieliśmy z systemem, jak opisujesz, jest to, że DEV może szybko przestać działać z PROD, więc nie rozwijasz się przeciwko live i nie jest łatwo wykryć wzajemne zależności aż do etapu. Powyższe rozwiązanie rozwiązuje te problemy, a jednocześnie pozostaje dość lekkie.
Nie miałem żadnych problemów ze wspólnymi tagami/oddziałami/organizacją pnia.
Generalny trwający rozwój odbywa się w bagażniku.
Utrzymanie wydania w produkcji odbywa się w odpowiedniej gałęzi wydania.
Zmiany w gałęzi wydania, które są nadal istotne dla łącza, są scalane.
Gdy nowa wersja jest gotowa do wdrożenia, jest oznaczana znacznikiem z magistrali, a następnie tworzona jest gałąź z tego znacznika. Nowa gałąź wydania jest sprawdzana na serwerze równolegle z bieżącą wersją. Kiedy nadchodzi czas zmiany, ścieżki są żonglowane ("mv appdir appdir.old & & mv appdir.new appdir").
Deweloperzy obsługujący wersję produkcyjną, a następnie svn przełączają swoją kopię roboczą do nowego oddziału lub robią z niej świeże zakupy.
Gorąco polecam książkę (obecnie w przybliżeniu) Continuous Delivery, która opisuje pełny proces zarządzania dostarczaniem oprogramowania, oparty na zasadach ciągłej integracji (między innymi).
Zdecydowanie nie podoba mi się podejście branżowe i scalające, ponieważ może być bardzo niechlujne i jest dość nieekonomiczne, ponieważ kończysz spędzanie czasu na działaniach, które w rzeczywistości nie przynoszą żadnej nowej wartości. Już raz opracowałeś, przetestowałeś i naprawiłeś swój kod, po co tworzysz sytuację (kopiujesz kod do innej gałęzi), co wymaga ponownego wykonania tej pracy?
W każdym razie sposobem na uniknięcie rozgałęziania się i łączenia jest tworzenie artefaktów z bagażnika i promowanie budowanych artefaktów (a nie źródeł) podczas testowania, przemieszczania itp. W ten sposób masz 100% pewności, że Rzecz, którą wkładasz w produkcję, to to, co testowałeś.
Jeśli masz różne funkcje, które mogą wymagać wydania w różnych harmonogramach, zmiana podejścia do sposobu implementacji (konfiguracja funkcji, lub lepiej, ale modularna) może pomóc w utrzymaniu pojedynczego stanowiska rozwojowego.
Książka jest już dostępna i wydaje się, że jest dobra z tego, co przeczytałem. –
Podoba mi się to, ale jak zachować aktualizacje bazy danych zgodnie z tą metodą? – cgreeno
kod strony internetowej obsługuje aktualizacje bazy danych z adresu URL administratora, a tam jest "numer wersji" bazy danych, aby wiedzieć, kiedy uaktualnić. –