Dobre wdrożenie Git przy użyciu strategii oddziału w Heroku?

Question

Co to jest dobra strategia wdrażania do używania z Git + Heroku (Ruby on Rails)?

Obecnie sposób, w jaki pracuję z moim źródłem pochodzenia Repozytorium Git: Wszystkie funkcje (lub "historie") są najpierw sprawdzane jako gałęzie, a następnie łączone z wzorcem i przekazywane do miejsca pochodzenia.

Wszystko, co zostało przekazane do miejsca pochodzenia/wzorca, uruchamia skrypt, który ściąga nowy kod szyny do obszaru przemieszczania (prosty rails webserver).

Kiedy nadejdzie czas, aby wypchnąć nową wersję produkcyjną do Heroku, czy powinienem utworzyć nowy oddział (nazywany czymś takim jak production_version_121), i wepchnąć to jakoś do Heroku?

Idealnie chciałbym wybrać i wybrać funkcje z poprzednich wersji rozwojowych, które powinienem dołączyć do gałęzi produkcyjnej ... przetestować i wcisnąć do Heroku.

Na przykład, może nie chcę, aby cały najnowszy kod został przekazany do produkcji. Mogę chcieć funkcji "a", nad którą pracowałem, i funkcji "c", w jakikolwiek sposób połączonej z produkcją, bez włączania funkcji eksperymentalnej "b", która wymaga więcej debugowania.

N.B. Zamierzam najpierw spróbować ominąć capistrano i na razie coś zrobić ręcznie.

Myśli? Najlepsze praktyki?

Answer 1

W projekcie Gemcutter mamy po prostu oddział production.Wszelkie zmiany, które chcemy zobaczyć w miejscu wydobycia się połączyły w tej branży, a następnie wdrożony z:

git push heroku production:master 

staging oddział służy podobnemu celowi na miejscu postoju (także na Heroku)

Answer 2

Istnieje wiele sposobów na zrobienie tego, a to naprawdę zależy od twoich preferencji.

Dam ci jedną możliwą strategię z mojej głowy: Biorąc pod uwagę, że masz już zautomatyzowaną konfigurację przemieszczania, która używa wzorca, proponuję utworzyć gałąź "produkcji". Jeśli chcesz promować poprawkę/funkcję do produkcji, wystarczy po prostu połączyć gałąź tematu z gałęzią "produkcyjną".

git checkout production 
git pull . my-topic-branch 
(resolve any conflicts) 

Gdy jesteś gotowy, aby faktycznie Push że kod na serwerze produkcyjnym, należy tag gałąź użyciu unikalną nazwę (prawdopodobnie ze znacznikiem czasu). Następnie wystarczy popchnąć gałąź produkcyjną do Heroku.

git checkout production 
git tag release-200910201249 

Sugeruję utworzenie skryptu lub git alias zautomatyzować tagowania dla znaczników czasu, ponieważ za pomocą spójnego systemu nazewnictwa jest bardzo ważne. Używam coś takiego:

git config alias.dtag '!git tag release-`date "+%Y%m%d%H%M"`' 

który pozwala mi zrobić wystarczy wpisać git dtag kiedy chcę, aby oznaczyć zwolnienie z datownik.

Możesz wyświetlać tagi za pomocą git tag i wyświetlać je za pomocą git show release-1234. Aby uzyskać więcej informacji na temat tagów, uruchom git help tag. Pomocna może okazać się również ta pomoc przy oznaczaniu Github guide. Polecam również czytanie przepływów pracy innych osób (tutaj: a nice writeup) i wybieranie i wybieranie tego, co działa dla Ciebie.

Answer 3

Kiedykolwiek od kiedy przeczytałem Vincenta Driessena A successful Git branching model, byłem uzależniony. Cała moja firma (8 osób) ustandaryzowała już ten model i kilka innych miejsc, z którymi się konsultowałem, również zaczęło go używać.

Większość osób, które pokazałem, mówi, że robili już coś podobnego i bardzo łatwo się przystosowali.

W skrócie, masz 2 gałęzie, które są trwałe (opanuj i rozwijaj). Przez większość czasu po prostu tworzysz gałęzie, które się rozwijają, i łączysz je z powrotem w rozwój. Sprawy stają się nieco bardziej złożone, gdy zaczynasz produkować premiery i poprawki, ale po przeczytaniu posta kilka razy, staje się on zakorzeniony.

Istnieje nawet narzędzie wiersza poleceń o nazwie git-flow, które może Ci pomóc.