Jaki jest sugerowany przepływ pracy przy migracji konfiguracji (CMI) z dev -> stage -> produkcja?

41

Kilka miesięcy temu mieliśmy drupalcamp i ktoś zapytał o zarządzanie wdrożeniami w nowym systemie config (CMI). Jednym z możliwych idealnych przepływów pracy byłoby utrzymanie konfiguracji pod kontrolą wersji i wciąż możliwość migracji konfiguracji między członkami zespołu.

Najlepsze, co udało nam się ustalić w pokoju (częściowo na podstawie prezentacji w DrupalCon Portland):

Powiedz kontroli wersji, aby zignorowała aktywny katalog konfiguracji.
Skopiuj całą konfigurację do katalogu pomostowego i przeprowadź kontrolę wersji.

I użyj settings.php, aby odwrócić katalog active / staging między dwoma środowiskami. Jednak opracowanie schematu przepływu pracy z jednego serwera na drugi było skomplikowane, ale wykonalne, jaki jest sugerowany przepływ pracy z wielu lokalnych środowisk (tj. Wielu programistów) do deweloperów (lub między sobą) - Możliwym problemem byłby każdy członek zespołu współdzieliby to samo lub podobne środowisko, więc w jaki sposób pojawiają się zmiany na komputerze jednego członka drużyny?

migration 8 version-control

— btmash
źródło

5

Naprawdę nie zgadzam się z obecnymi bliskimi głosami. Ponieważ CMI skupia się na Drupal 8, myślę, że możemy tu znaleźć kilka dobrych odpowiedzi.

— mpdonadio

3

Zgadzam się, to bardzo dobre pytanie. Uważam, że krytyczne zadanie drupal.org/node/1703168 dotyczy tego i innych tematów i nie zostało jeszcze całkowicie rozwiązane, więc odpowiedzi tutaj mogą pomóc w rozwiązaniu tego problemu.

— Berdir

Przepraszam, jeśli moje pytanie okazało się negatywne w stosunku do inicjatywy CMI (co wcale nie było moim zamiarem). Zaktualizowałem pytanie, aby brzmiało bardziej neutralnie.

— btmash

2

prawie chciałem powiedzieć „Wypróbowałeś już funkcje”. Może „D8” powinien znaleźć się w tytule pytania? Znacznik „8” jest trochę niewidoczny.

— donquixote

1

Zmieniono tytuł, aby pytanie było widoczne zarówno według tagu, jak i tytułu :)

— btmash,

19

Po krótkiej rozmowie z opiekunami CMI dyskusja na temat najlepszego podejścia nie została zakończona, ale w tej chwili najbardziej sensowna jest następująca.

Starając się na razie zachować zwięzłość, postaram się rozwinąć w oparciu o pytania / kiedy problem, który dotyczy, zostanie rozwiązany za pomocą oficjalnej odpowiedzi.

Po pierwsze, fakty ...

Jak już wspomniano, istnieje katalog aktywny i tymczasowy. Aktywny jest w pełni zarządzany przez Drupala, wprowadzanie zmian bezpośrednio w nim (bezpośrednie lub pośrednie poprzez przejście do innej lokalizacji) nie jest obsługiwane.
Inscenizacja polega na tym, że Drupal szuka konfiguracji do zaimportowania, a w przeciwnym razie nie przejmuje się nią.
Proces importowania jest ważny, zmiany konfiguracji mogą w określony sposób wpłynąć na witrynę i należy je sprawdzić pod kątem ważności. Nie można zmienić typu pola tekstowego na odwołanie do encji, na przykład to po prostu nie działa.
Import konfiguracji musi zawsze przebiegać dla wszystkich konfiguracji, nie można zaimportować pojedynczego widoku lub typu węzła. Próbowano go poradzić, ale próba radzenia sobie z zależnościami, usuwanie / zmiana nazw itp. Zaowocowała bardzo skomplikowanym systemem i nie działało.
Jedynym sposobem na ponowne zainstalowanie domyślnej konfiguracji jest ponowna instalacja tego modułu. Co oznacza, że najpierw spróbuje usunąć całą konfigurację (jak pola). Więc to nie jest tak naprawdę opcja. Myślę, że ręczne, określone zmiany w funkcjach aktualizacji są możliwe, ale zbyt żmudne.
Jak opisuje moduł funkcji, będzie on koncentrował się na zapewnieniu funkcjonalności wielokrotnego użytku, a nie na ciągłym wdrażaniu konfiguracji. Właśnie po to został zaprojektowany.

Biorąc to pod uwagę, zaleceniem jest teraz wprowadzenie katalogu pomostowego do kontroli wersji. Każdy programista ma wówczas pełną kontrolę nad tym, co tam umieszcza, kopiując cały katalog aktywny lub tylko określony plik konfiguracyjny. Zmiany katalogu pomostowego są następnie zatwierdzane, przekazywane do produkcji i uruchamiany jest import konfiguracji (w interfejsie użytkownika lub z drush).

— Berdir
źródło

Katalog pomostowy w kontroli wersji, dostaję tę część. Pozostałe części są tym, co mój umysł próbuje przetworzyć. Jeśli więc ktoś dokona zmiany, skopiuje swoje zmiany do katalogu pomostowego i zatwierdzi je. Po tym momencie inni deweloperzy / następny serwer otrzymują zmiany i synchronizują zmiany z katalogiem aktywnym. I przepłucz i powtórz dla dowolnego innego łańcucha serwerów po drodze (inscenizacja, produkcja itp.) I zawsze przechodzi przez etapy, więc nie ma już potrzeby przełączania katalogów. Czy to by było dokładne?

— btmash

Tak. Nie może być przełączania katalogów. Każda zmiana konfiguracji musi przejść proces importowania, w przeciwnym razie może dojść do uszkodzenia strony. Na przykład lista modułów to także konfiguracja. Wdrożenie oznacza, że moduły muszą zostać zainstalowane / odinstalowane (Uwaga: To jeszcze nie działa, ale jest problem, aby to naprawić).

— Berdir

Ok, więc teraz jeszcze więcej pytań (podzielone na 2 komentarze) :) Po pierwsze, wspominasz, że moduły to konfiguracja. Więc nawet jeśli moduł jest dodawany do repozytorium i nie jest włączony / wyłączony, należy go zainstalować / odinstalować, aby po prostu tam siedzieć?

— btmash

I kontynuacja: (A) Czy będzie mechanizm kopiowania zmian z katalogu aktywnego -> przemieszczanie (aby uprościć w stosunku do osoby wchodzącej do katalogu konfiguracji dla tych składników - być może sposób na wybranie pewnych zmiennych). (B) Czy katalog pomostowy jest opróżniany po zsynchronizowaniu zmian z pomostowania -> aktywny? (B1) Jeśli tak, to czy z punktu widzenia devops strategia polega na zresetowaniu tego katalogu przed ściągnięciem git? (B2) Jeśli nie, to czy słusznie jest założyć, że w trakcie przemieszczania> aktywna synchronizacja nie powinna mieć wpływu na konfigurację, która nie uległa zmianie?

— btmash

Status instalacji modułu to konfiguracja. Nie sam moduł :) To właśnie wdrażasz. a) Istnieje interfejs do pobrania tar.gz katalogu aktywnego, jeden do przesłania wspomnianego tar.gz do katalogu pomostowego i jeden do faktycznego wykonania importu, z przeglądem i różnicą zmian. B) Wierzę, że teraz jest opróżniony, ale zakładam, że możesz łatwo to cofnąć za pomocą git. Nie jestem pewien, łatwo to sprawdzić. Wszystkie te rzeczy można podłączyć, więc może istnieć nieco inna implementacja, która nie usuwa. B2) Nie dostaję tego, ale myślę, że tak.

— Berdir,

4

Jak dotąd świetnie odpowiedział. Dziękuję wam wszystkim!

Niedawno rozpoczęliśmy projekt Drupal 8 i wdrożyliśmy następujący przepływ pracy.

Posiadamy trzy foldery aktywne, tymczasowe i eksportowe. Deweloperzy zrzucają je na eksport. Nie chcę tego robić na scenie. Myślę, że łatwiej jest pracować, gdy wspólna konfiguracja nie jest bezpośrednio przechowywana w folderze pomostowym. To tylko wycinka, na którą nie mam twardych faktów ...

Nasz aktualny szablon projektu drupal 8 jest dostępny na github. Napisałem też kilka przydatnych poleceń drush, aby przyspieszyć przepływ devleoper. Nie jest wymagane ręczne kopiowanie z aktywnego na eksport.

Szablon projektu: https://github.com/webflo/d8-project-template
Dodatkowe polecenia Drush: https://github.com/webflo/d8-project-template/blob/master/public/drush/cmi.drush.inc

— webflo
źródło

1

Jak dotąd zgadzam się z tym podejściem. Dodałem wszystkie funkcje z linków w tym poście do poleceń Drush config-export i config-import. Mam nadzieję, że inni dołączą do mnie i @florian podczas eksploracji tego 3-katalogowego rozwiązania.

— moshe weitzman

Jak sobie radzić z sites/default/files/config_HASHfolderem config z przyrostkiem skrótu, np. Config_wNOLcmycPFZCrXJ9wis9dCdSR4lpYILdBsFxSWuK5Hzhcr

— therobyouknow

@therobyouknow Możliwe jest zastąpienie lokalizacji tych folderów. Wystarczy wyszukać „Lokalizacja plików konfiguracji witryny”. w settings.php Używam następującego fragmentu kodu. Oznacza to, że konfiguracja jest przechowywana poza katalogiem głównym Drupals. $ config_directories = array ('active' => '../config/active', 'staging' => '../config/staging',);

— webflo,

Dzięki @webflo widziałem to. Jaka byłaby korzyść z osobnego zarządzania bazą kodu i konfiguracją? Myślę, że ta separacja jest trochę sztuczna, ponieważ zarówno kod, jak i config (w yaml) określają zachowanie i są od siebie zależne. W Drupal 7 konfiguracja w kodzie (lub śledzenie przez Git) została wykonana z modułem Features, który utworzył moduł dla każdej konfiguracji wymagającej śledzenia w kodzie. W Drupal 8 są funkcje 3.x, które, jak rozumiem, robią to samo, ale używają YAML do przechowywania konfiguracji, a generowane moduły nie są zależne od modułu Funkcje.

— therobyouknow

Myślę, że mnie źle zrozumiałeś, katalog konfiguracji wciąż jest w git, ale moja strona Drupal nie znajduje się w katalogu głównym repozytorium git. Witryna jest przechowywana / internetowa. Więc / config i / web są na tym samym poziomie.

— webflo

2

Jeszcze tego nie próbowałem, ale moim planem jest utworzenie niestandardowego modułu zawierającego „domyślne” pliki konfiguracyjne zawierające tylko konfigurację, na której mi zależy. Wierzę, że inne moduły mogą zawierać konfiguracje, które zastępują inne moduły. (Jeśli nie, należy to umożliwić).

Myślę, że musisz zostawić folder config w spokoju. Zignoruj to. Jest generowany automatycznie podczas instalacji ze wszystkich plików konfiguracyjnych poszczególnych modułów. Ścieżka jest długa i losowa. Jeśli zachowałeś to wszystko w repozytorium, potrzebowałbyś osobnego repozytorium i miałbyś przy sobie mnóstwo domyślnych, niepotrzebnych plików konfiguracyjnych.

Umieszczenie config w niestandardowym module czyni go częścią twojej głównej bazy kodu.

Proces wdrażania byłby następujący:

Git pull lub cokolwiek, aby uzyskać nowe pliki.
Wyczyść pamięć podręczną.
Zresetuj domyślną konfigurację. (Z plików niestandardowego modułu)

Jeśli chcesz, możesz utworzyć niestandardowe moduły (z własną konfiguracją) dla każdego środowiska.

— jonpugh
źródło

To brzmi jak funkcje, prawda? A może brakuje mi znaczącej różnicy?

— Letharion,

To ciekawe podejście i podoba mi się ten pomysł. Jedną z największych zalet, o której wspomniano w ramach inicjatywy CMI, jest możliwość przejścia z konfiguracji przez katalogi konfiguracji. I z tego, co widzę, plik settings.php pozwala dyktować, gdzie znajdują się katalogi aktywne / pomostowe (tzn. Nie muszą to być automatycznie generowane ścieżki). Dlatego uważam, że przepływ pracy z bieżącą konfiguracją powinien być możliwy bez potrzeby tworzenia funkcji, jak wspomniano powyżej w @Letharion.

— btmash

2

Uwaga: Doceniam to, że nie jest to odpowiedź w najściślejszym sensie w odniesieniu do pytania, ale mimo to umieściłem ją tutaj i ponownie odwiedzę i edytuję / usuń, gdy Funkcje zostaną wydane w wersji 8.x, a kurz rozstrzygnął trochę więcej. To było po prostu za duże na komentarz i chciałem uzyskać 0,02 funta w :-)

Jako wielki fan Funków , sugeruję obserwowanie wcielenia D8 modułu Funkcji .

Zaczerpnięte ze strony projektu

Wersja 3.x Funkcji jest planowana do integracji z Drupalem 8 z nowym systemem zarządzania konfiguracją. Jeśli chcesz po prostu wyeksportować prostą konfigurację witryny, zamiast funkcji należy użyć systemu zarządzania konfiguracją D8. Będziesz używać funkcji w D8 do eksportowania funkcji pakietowej (np. „Funkcji galerii zdjęć”).

Tak jak ja trochę go zobaczyć, że ten pomysł ułatwia dev zespołów do pracy na mniejsze części witryny. Nie zamierzam jednak przechodzić jeszcze do przepływu pracy, ponieważ wciąż istnieje zbyt wiele nieznanych zmiennych, ale nie widzę, aby BARDZO różniła się od obecnej procedury wdrażania funkcji.

Nie mogę się powstrzymać, ale myślę, że tak, CMI jest niesamowity; ale większość moich stron nadal będzie mieć moduły funkcji (choć mniejszą ilość z powodu braku konieczności eksportowania KAŻDEGO typu treści, uprawnień itp.)

— Chapabu
źródło

Chociaż zgadzam się, że funkcje nieznacznie zmienią swoją rolę i (mam nadzieję) będą narzędziem do łączenia ze sobą komponentów konfiguracji (jak wspomniana funkcja galerii zdjęć), konfiguracja (o ile rozumiem) będzie nadal utrzymywana przez aktywny katalog konfiguracji. Funkcje mogą więc rozwiązać określony komponent, ale prawdziwym problemem jest sposób zarządzania przepływem pracy w katalogu konfiguracji w różnych środowiskach. Procedura wdrażania różni się nieco od procedury wdrażania bieżących funkcji, przede wszystkim dlatego, że dane magazynu aktywnego znajdują się w bazie danych, a magazyn danych to pliki.

— btmash

... procedura wdrażania funkcji d7 obejmuje dane magazynu danych aktywnych w bazie danych i magazynu danych w plikach. Przechodzimy do obu plików i musimy tylko upewnić się, jak wpływa to na zmianę przepływu pracy.

— btmash

Zauważ, że funkcje naprawdę nie mają pojęcia aktywnego i magazynu danych / przemieszczania. A przynajmniej niespójne, wszystko zależy od konkretnego haka / rzeczy, z którą się integruje. Domyślne widoki są w kodzie, na przykład zmiany są natychmiast aktywne (oprócz buforowania), nie ma kontrolowanego procesu wdrażania z funkcjami. To zawsze był jednym z głównych problemów podczas używania funkcji do wdrażania.

— Berdir

Masz rację. Nie wiem, jak zmiksowałem moduł konfiguracji dla D7 z funkcjami, ale tak zrobiłem.

— btmash