Witam, chciał bym zaczerpnąć więcej wiedzy na temat pracy w dużych zespołach nad produktami. Dokładniej chodzi workflow zarówno od strony organizacyjnej (tutaj dość łatwo można znaleźć coś w internetach) jak i od strony technicznej (no i tutaj coś konkretnego znaleźć jest cieżko).
Jeśli chodzi o organizacje to tutaj mamy dość prosty i popularny gitflow: http://nvie.com/posts/a-successful-git-branching-model/ [moze jakieś inne polecicie?]
Natomiast od strony technicznej, wygląda to dużo trudniej. Środowiska produkcyjne, testowe i preprodukcyjne są raczej proste, natomiast środowiska developerskie są nieco trudniejszą sprawą. Do głowy przychodzi mi vagrant lub VPSy. Problemem jest natomiast skala. Jeśli zespół jest 5 osobowy i mamy ze 2 produkty, to jest to tylko 10 środowisk na serwerach lub ściągamy developerom te 2 produkty na lokalny sprzęt. Natomiast jeśli programistów jest 50 a produktów 20, to mamy 1000 środowisk developerskich do ogarnięcia lub musimy lokalnie ściągnąć 20 produktów co wiązać się będzie ze sporym wydatkiem na sprzęt.
Jak żyć? jak ktoś ma własne doświadczenia to chętnie je przeczytam, dobrą literaturą też nie pogardzę. Nie musi być koniecznie po polsku.

Z góry przepraszam, jeśli temat był poruszany. Używałem szukajki ale nic nie znalazłem związanego z tym zagadnieniem.

Tak na szybko, jak to wygląda u mnie:
1. Środowisko deweloperskie jest zainstalowane na maszynie programisty i w miarę możliwości zawiera wszystko co potrzebne do odpalenia w pełni funkcjonalnego projektu.
2. Wszystkie środowiska (prod/test/dev) zarządzane są przez pojedynczą konfigurację w Chefie (możesz skorzystać również z Puppeta czy Ansible'a).

Docker to the rescue. Środowisko dev na którym pracuje ma postawionych 8 "maszyn" (kontenerów), działa to dobrze nawet na laptopie. Kwestia tego aby przesiąść się na linuksa. Różnicy pomiędzy środowiskami prawie nie ma, z wyjątkiem produkcyjnej wersji, gdzie każdy kontener jest na osobnej maszynie. Konfiguracja jest prawie ta sama, różni się niektórymi zmiennymi środowiskowymi (wiadomo), postawienie środowiska developerskiego, to kwestia wykonania komendy docker-compose up -d i poczekania aż stosowne obrazy się pobiorą (coś ala vagrant). Jeżeli do wszystkich kontenerów jest stosowany jeden system, to wszystko ładnie się uruchamia. 2-3 sekundy na wystartowanie 8 kontenerów (mongodb, redis, nodejs x3, nginx, php, haproxy).

Wcześniej pracowaliśmy na vagrancie, ale kiedy przyszło nam testować klastrowanie niektórych usług, zaczęło być niefajnie, a ludzie na laptopach zaczęli płakać. Aktualnie siedzimy na maszynach za jakieś ~2.5 tyś zł (razem z monitorami), a docker śmiga aż miło. Nawet odpalenie i 100 kontenerów nie będzie żadnym wyzwaniem. Więc porównanie z vagrantem jest spore. Dzięki temu mogę odpalić lokalnie konfigurację produkcyjną, i sprawdzić czy mongodb lub redis w klastrze będą działać. Im dalej w ten temat się zagłębiam, tym bardziej nie chce wracać do vagranta lub windowsa. Cholera nawet CI mamy postawione jako kontener, który buduje kontenery (incepcja).

Tak na szybko tutaj masz przykład jak to mniej więcej wygląda u mnie: https://www.airpair.com/docker/posts/effici...-docker-compose z tą różnicą, że nie używamy submodułów, bo ich aktualizacja jest problematyczna.

@by_Ikar chyba na korepetycje z Dockera się uśmiechę

@Pyton_000 chętnie mogę wytłumaczyć pewne kwestie, które będą niezrozumiałe, lub będzie jakiś brak informacji na ich temat. Docker jest na prawdę świetny, zwłaszcza ostatnie aktualizacje z łączeniem kontenerów pomiędzy różnymi hostami, że kontenery będąc na różnych maszynach, będą miały ze sobą połączenie, jakby to była odpalona lokalna sieć (vxlan). Śmiało można jakiś wątek założyć (lub nawet dział), pewnie jest jeszcze sporo innych osób które chętnie w tym temacie by się wypowiedziały.

Zależy na jakim etapie jest projekt, na etapie rozwoju lub wdrożenia:
1. polecam model pracy z gitem: git-flow: http://nvie.com/posts/a-successful-git-branching-model/
2. korzystanie z pull requestów oraz code review w popularnych nakładkach na gita np. bitbucket.org lub gitlab
3. używanie systemów ticketowych np. redmine albo jira i zintegrowanie ich z np. hipchatem (jira - hipchat), używanie w nich sprintów
4. do tego dochodzi standardowa poczta, codzienne spotkania w SCRUMie, raz w tygodniu planningi
5. należyte opisywanie zadań w systemach ticketowych, używając user stories oraz kryteriów akceptacyjnych