Jako, że rozwinęła się dyskusja z @Shalom w komentarzach to tworzę nowy wątek bo może inni też nie znają takiego podejścia.
Jak pracowałem w Instagramie to pracowaliśmy wszyscy na jednym branchu - Master. Nie było feature branchy (z tego co wiem to nadal nie ma bo to się sprawdza)
Zalety:
- Łatwiejsza współpraca. Nie trzeba się zastanawiać w jakim repo czy branchu dany feature jest rozwijany.
- Łatwiej dzielić zmiany na mniejsze części.
- Łatwiej cofać zmiany jeśli jest to konieczne
- Można kontrolować wydajność danych feature jednocześnie w trakcie rozwoju bez dodatkowych narzutów
Skoro każdy feature jest rozwijany na masterze to jak dostarczamy kod do użytkowników?
W Instagramie to wyglądało/wygląda tak, że każdy feature jest dostępny najpierw tylko dla określonych użytkowników np. dla programistów. Potem dla QA (coś w tym stylu, co prawda w Instagramie inaczej te role się nazywały i miały trochę też inne obowiązki) - tutaj mogą dać już feedback (wcześniej też) żeby programiści mogli kontynuować pracę.
Następnie dla wszystkich pracowników. Potem część użytkowników np. 0,5% USA. Jeśli wszystko jest ok to feature jest włączany dla wszystkich.
Tak proces może trwać tydzień a może trwać i miesiąc.
Pomiędzy są też load testy żeby wiedzieć czy jeśli każdy by mógł używać to serwery by to wytrzymały itd.
Jak myślicie jak często wrzucany jest kod na Produkcję? Raz na tydzień? Raz na dzień? A co powiecie na raz na commit?
W tamtym okresie było to około 30-70 rolloutów na dzień.
Taki typowy commit znajduje się na prodzie w ciągu godziny od wejścia do mastera.
Wymagania:
- Każda zmiana musi być działająca
- Code review
- unit testy
- Zbieranie informacji o błędach i porównywanie liczby błędów pomiędzy serwerami. Czyli zanim zmiana pójdzie na np. 40 000 serwerów to najpierw ląduje na 2-3 serwery i porównywany jest % błędów. Jeśli znacznie rośnie to wiadome, że coś jest nie tak.
- Alarmy itd. żeby jak najszybciej wykrywać błędy