To pytanie bierze przykład usługi Spring Boot, ale może to być dowolna technologia.
Zakładając, że:
- Środowiska (dev / QA / prod) są własnością różnych zespołów. Oznacza to, że dev nie może mieć dostępu do konfiguracji prod.
- Konfiguracja (powiedzmy application.properties) jest uzewnętrzniona, tzn. Nie jest częścią pliku binarnego
- Ten sam plik binarny / pakiet (powiedzmy service.jar) jest wdrażany w każdym środowisku i kontrolowany przez automatyczne wdrażanie
Podczas gdy zmiany w binarnym artefakcie (service.jar) są automatycznie propagowane do każdego środowiska, zmiany w konfiguracji nadal wymagają ręcznej interwencji, co nieuchronnie kończy się synchronizacją w każdym środowisku.
Załóżmy na przykład, że zespół programistów dodaje kilka par klucz-wartość do application.properties w swoim środowisku. Jaki byłby najlepszy sposób rejestrowania tych nowych kluczy, aby podczas wdrażania w zespole operacyjnym wiedzieli dokładnie, które klucze należy dodać, aby zminimalizować ryzyko uruchomienia nowej usługi i nieudanej próby z powodu braku klucza?
Wiem, że będą to ręczne kroki, ale chciałbym wiedzieć, jak ludzie sobie z tym radzą i znaleźć najbardziej skuteczny sposób.
źródło
Odpowiedzi:
Jest to głównie problem z komunikacją, ale błędy mogą być mniej prawdopodobne dzięki prostym środkom technicznym i organizacyjnym. Po pierwsze, powinieneś dostarczyć dobrą, wysokiej jakości dokumentację wszystkich wpisów w plikach konfiguracyjnych, a także łatwo dostępny przykład lub „domyślny” plik konfiguracyjny. Przykładowy plik może zostać automatycznie wdrożony w każdym środowisku, ponieważ nie jest przeznaczony do bezpośredniej zmiany przez zespół prod.
Następnie, z każdą nową wersją, dostarczaj dziennik zmian, w którym dokumentowane są ważne zmiany. Zmiany w konfiguracji, które mogą uniemożliwić działanie systemu, gdy go brakuje, są zawsze ważne, więc upewnij się, że informacje tam są.
Najlepszym sposobem na zmniejszenie ryzyka niepowodzenia jest uniknięcie zmiany aplikacji w taki sposób, aby wymagała nowych kluczy, dlatego aplikacja powinna być kompatybilna wstecz ze starszymi plikami konfiguracyjnymi, gdy tylko jest to możliwe. Często aplikacja może zachowywać się w rozsądny sposób, podając wbudowane wartości domyślne dla nowych kluczy w przypadku ich braku.
Jeśli jednak nie jest to możliwe, Twój system powinien maksymalnie ułatwić zespołowi prod, aby dowiedzieć się, dlaczego nowa usługa nie uruchamia się, gdy brakuje klucza. Powinien pojawić się wyraźny komunikat o błędzie, informujący dokładnie, którego klucza brakuje w jakim pliku , a jeśli to konieczne, gdzie znaleźć informacje o brakującym kluczu lub wskazówkę lub przykład na temat znaczącej pozycji dla tego klucza.
Jeśli konfiguracja jest złożona, a format zmienia się w taki sposób, że ręczna edycja staje się podatna na błędy, możesz również rozważyć udostępnienie narzędzi do edycji konfiguracji i migracji do nowszej wersji.
Na przykład korzystam z przeglądarki internetowej Firefox i wraz z każdą nową wersją (którą otrzymuję automatycznie) do konfiguracji lokalnej dodawane są pewne elementy, które można sprawdzić na stronie „about: config”. Jest to porównywalne z konfiguracją w środowisku „produkcyjnym”. Ponieważ cała konfiguracja jest ściśle zgodna z poprzednimi wersjami, nigdy nie muszę ręcznie dodawać nowych kluczy do konfiguracji tylko dlatego, że pojawiła się nowa wersja przeglądarki. W przypadku, gdy chcę coś tam zmienić (być może nowy wpis, który nie był częścią poprzedniej wersji), albo używam menu Narzędzia / Opcje, albo strony „about: config” i mogę znaleźć wpis plus trochę rodzaj dokumentacji. Dlatego zalecam próbę wdrożenia systemu w podobny sposób.
źródło
W jednym miejscu, w którym kiedyś pracowałem, mieli podobny problem. Konfiguracja produkcji była kontrolowana przez zespół budujący, tylko oni mieli do niej dostęp w repozytorium kodu. Konfiguracje dev, qa, test itp. Mogą być widoczne dla każdego.
W twoim przykładzie programista zaktualizowałby plik lokalnie, zameldował go w celu kontroli źródła, a następnie ktoś poprosił zespół budujący o wykonanie nowej kompilacji „tylko konfiguracja”, która wyewidencjonowała pliki konfiguracyjne i wdrożyła je, ale nie dokonała ponownej kompilacji lub ponownie wdróż całą aplikację.
Członkowie zespołu powinni aktualizować pliki konfiguracyjne dla innych środowisk w odpowiednim czasie. Kiedy nadszedł czas na aktualizację do produkcji, zespół budujący musiał zaktualizować plik, za pośrednictwem wyraźnego żądania od kierownika zespołu programistów, chociaż zwykle żądanie wyglądało po prostu „skopiuj plik app.config z QA1 do PROD”. Wrażliwe elementy, takie jak hasła, znajdowały się w osobnym pliku konfiguracyjnym i ponownie tylko zespół budowniczy mógł uzyskać dostęp do pliku hasła produkcyjnego. Różnica polegała na tym, że deweloperzy zwykle nie nieżądać zmian w plikach haseł, ponieważ nie mieliby oni haseł produkcyjnych. Jedyny raz poprosili zespół kompilacyjny o zaktualizowanie go podczas dodawania nowego hasła do nowej usługi. I nawet wtedy programiści prawdopodobnie nie znaliby hasła produkcyjnego, znali tylko klucz do dodania do pliku (na przykład „newService2.password”).
Technologią używaną do zarządzania wieloma z nich była Jenkins. Było też wewnętrzne narzędzie, które było używane do żądania i planowania kompilacji za pośrednictwem Jenkins.
źródło