Jeśli używasz Spring Cloud Config warto zwrócić uwagę na to jak wygląda twoja organizacja konfiguracji w repozytorium GIT. Dobre jej zaprojektowanie umożliwi Ci wykorzystanie pełnej historii, tagów oraz branchy w sposób efektywny.

Założenia naszego ekosystemu

Na początek, zdefiniujmy kilka założeń, aby było jasne jaką sytuację rozważamy.

• mamy wiele aplikacji
• każda aplikacja to ekosystem mikroserwisów
• mamy 4 środowiska: dev, uat, stage i prod
• na chwilę obecną, mamy 2 aplikacje składające się z kilku mikroserwisów:
  • SHOP
    • shop-invoices
    • shop-products
  • CRM
    • crm-customers
    • crm-mail

Spójrzmy teraz na cztery opcję przygotowania repozytorium i skonfigurowania serwera.

1. Repozytorium per aplikacja i branch per środowisko
2. Branch per aplikacja i środowisko
3. Branch per aplikacja
4. Branch per środowisko

Od razu zaznaczę, że zdecydowanie, moim faworytem jest pierwsza opcja, ponieważ daje nam największą elastyczność. Jednak, drugi wariant jest też dosyć dobrym kompromisem, jeśli chcemy mieć tylko jedno repozytorium. Przeanalizujmy każdą opcję z osobna.

1. Repozytorium per aplikacja i branch per środowisko

Zawartość repozytorium

(dev) shop-invoices/application.yml
(dev) shop-products/application.yml

(uat) shop-invoices/application.yml
(uat) shop-products/application.yml

(stage) shop-invoices/application.yml
(stage) shop-products/application.yml

(prod) shop-invoices/application.yml
(prod) shop-products/application.yml

(dev) crm-customers/application.yml
(dev) crm-mail/application.yml

(uat) crm-customers/application.yml
(uat) crm-mail/application.yml

(stage) crm-customers/application.yml
(stage) crm-mail/application.yml

(prod) crm-customers/application.yml
(prod) crm-mail/application.yml

Konfiguracja dla Spring Cloud Config Server

spring:
   cloud:
     config:
       server:
         git:
           uri: "https://github.com/lmonkiewicz/config-example"
           repos:
             shop:
                 pattern: shop-*
                 uri: "https://github.com/lmonkiewicz/shop"
                 search-paths:
                     - '{application}/'
                 default-label: 'main'
             crm:
                 pattern: crm-*
                 uri: "https://github.com/lmonkiewicz/crm"
                 search-paths:
                     - '{application}/'
                 default-label: 'main'

W aplikacjach klienckich używamy parametru label jako nazwy środowiska (dev, uat, state, prod).

Plusy

• Każda aplikacja jest odseparowana od pozostałych
• Możliwość kontroli uprawnień per repozytorium i dodatkowo per branch (do aplikacji i do środowisk)
• Możemy użyć profili springowych
• Możemy użyć git merge do przenoszenia konfiguracji ze środowiska niższego na wyższe.
• Mała ilość branchy
• Możemy użyć tagów gita w celu wersjonowania konfiguracji (np. crm_mail_2.1.3)

Minusy

• Każde nowe repozytorium musimy dodać do konfiguracji serwera
• Każde repozytorium musimy od nowa skonfigurować

2. Branch per aplikacja i środowisko

Zawartość repozytorium

(shop_dev)   shop-invoices/application.yml
(shop_dev)   shop-products/application.yml
(shop_uat)   shop-invoices/application.yml
(shop_uat)   shop-products/application.yml
(shop_stage) shop-invoices/application.yml
(shop_stage) shop-products/application.yml
(shop_prod)  shop-invoices/application.yml
(shop_prod)  shop-products/application.yml

(crm_dev)   crm-customers/application.yml
(crm_dev)   crm-mail/application.yml
(crm_uat)   crm-customers/application.yml
(crm_uat)   crm-mail/application.yml
(crm_stage) crm-customers/application.yml
(crm_stage) crm-mail/application.yml
(crm_prod)  crm-customers/application.yml
(crm_prod)  crm-mail/application.yml

Konfiguracja dla Spring Cloud Config Server

spring:
   cloud:
     config:
       server:
         git:
           uri: "https://github.com/lmonkiewicz/config-example"
           search-paths:
             - '{application}/'
           default-label: 'main'

W aplikacjach klienckich używamy parametru label jako kodu aplikacji i środowiska, czyli np. crm_prod dla aplikacji CRM i środowiska PROD.

Plusy

• Możliwość kontroli uprawnień per branch (do aplikacji i do środowisk)
• Możemy użyć profili springowych
• Możemy użyć git merge do przenoszenia konfiguracji ze środowiska niższego na wyższe.
• Nie musimy modyfikować konfiguracji serwera dodając nową aplikację
• Możemy użyć tagów gita w celu wersjonowania konfiguracji (np. crm_mail_2.1.3)

Minusy

• Wszystkie aplikację są w jednym repozytorium
• Duża ilość branchy

3. Branch per aplikacja

Zawartość repozytorium

(shop)   shop-invoices/application.yml
(shop)   shop-invoices/application-dev.yml
(shop)   shop-invoices/application-uat.yml
(shop)   shop-invoices/application-stage.yml
(shop)   shop-invoices/application-prod.yml
(shop)   shop-products/application.yml
(shop)   shop-products/application-dev.yml
(shop)   shop-products/application-uat.yml
(shop)   shop-products/application-stage.yml
(shop)   shop-products/application-prod.yml

(crm)   crm-customers/application.yml
(crm)   crm-customers/application-dev.yml
(crm)   crm-customers/application-uat.yml
(crm)   crm-customers/application-stage.yml
(crm)   crm-customers/application-prod.yml
(crm)   crm-mail/application.yml
(crm)   crm-mail/application-dev.yml
(crm)   crm-mail/application-uat.yml
(crm)   crm-mail/application-stage.yml
(crm)   crm-mail/application-prod.yml

Konfiguracja dla Spring Cloud Config Server

spring:
   cloud:
     config:
       server:
         git:
           uri: "https://github.com/lmonkiewicz/config-example"
           search-paths:
             - '{application}/'
           default-label: 'main'

W aplikacjach klienckich używamy parametru label jako kodu aplikacji natomiast musimy używać profile aby wybrać odpowiednie środowisko.

Plusy

• Możliwość kontroli uprawnień per branch (do aplikacja)
• Nie musimy modyfikować konfiguracji serwera dodając nową aplikację
• Możemy użyć tagów gita w celu wersjonowania konfiguracji (np. crm_mail_2.1.3)

Minusy

• Brak możliwości kontroli uprawnień do środowiska
• Wszystkie aplikację są w jednym repozytorium
• Duża ilość branchy
• Nie możemy używać profili springowych
• Nie możemy użyć git merge do przenoszenia konfiguracji

4. Branch per środowisko

Zawartość repozytorium

(dev)   shop-invoices/application.yml
(dev)   shop-products/application.yml
(dev)   crm-customers/application.yml
(dev)   crm-mail/application.yml

(uat)   shop-invoices/application.yml
(uat)   shop-products/application.yml
(uat)   crm-customers/application.yml
(uat)   crm-mail/application.yml

(stage)   shop-invoices/application.yml
(stage)   shop-products/application.yml
(stage)   crm-customers/application.yml
(stage)   crm-mail/application.yml

(prod)   shop-invoices/application.yml
(prod)   shop-products/application.yml
(prod)   crm-customers/application.yml
(prod)   crm-mail/application.yml

Konfiguracja dla Spring Cloud Config Server

spring:
   cloud:
     config:
       server:
         git:
           uri: "https://github.com/lmonkiewicz/config-example"
           search-paths:
             - '{application}/'
           default-label: 'main'

W aplikacjach klienckich używamy parametru label jako nazwy środowiska.

Plusy

• Możliwość kontroli uprawnień per branch (do środowiska)
• Nie musimy modyfikować konfiguracji serwera dodając nową aplikację
• Możemy użyć profile springowe
• Mała ilość branchy
• Możemy użyć cherry-pick do przenoszenia konfiguracji między środowiskami
• Możemy użyć tagów gita w celu wersjonowania konfiguracji (np. crm_mail_2.1.3)

Minusy

• Brak możliwości kontroli uprawnień do aplikacji
• Wszystkie aplikację są w jednym repozytorium
• Nie możemy użyć git merge do przenoszenia konfiguracji ponieważ przenosimy konfigurację wszystkich aplikacji
• Mamy bardzo ograniczone możliwości wykorzystania tagów gita

Więcej informacji

• Dokumentacja konfiguracji GIT dla Spring Cloud Config