Dobry obieg pracy przy tworzeniu oprogramowania dzięki scrum i ciągłej integracji

Studiuję podejście, aby lepiej zrozumieć, w jaki sposób przepływ pracy ciągłej integracji lepiej pasuje w firmie zajmującej się tworzeniem oprogramowania metodą scrum.

Myślę o czymś takim:

Czy to byłby niezły przepływ pracy?

Jesteś na dobrej drodze, ale nieco rozwinąłbym twój schemat:

Zasadniczo (jeśli pozwala na to kontrola wersji, tj. Jeśli korzystasz z hg / git), chcesz, aby każda para programistów / deweloperów miała własną „osobistą” gałąź, która zawiera historię jednego użytkownika, nad którą pracują. Po ukończeniu funkcji muszą pchnąć do centralnej gałęzi, gałęzi „Release”. W tym momencie chcesz, aby deweloper otrzymał nową gałąź, aby dalej nad tym pracować. Oryginalną gałąź funkcji należy pozostawić bez zmian, więc wszelkie zmiany, które należy wprowadzić, można wprowadzić oddzielnie (nie zawsze ma to zastosowanie, ale jest to dobry punkt wyjścia). Zanim programista powróci do pracy nad starą gałęzią funkcji, powinieneś pobrać najnowszą gałąź wydania, aby uniknąć dziwnych problemów z scalaniem.

W tym momencie mamy możliwego kandydata do wydania w postaci gałęzi „Release” i jesteśmy gotowi do uruchomienia naszego procesu CI (w tej gałęzi, oczywiście można to zrobić w każdej gałęzi programisty, ale jest to dość rzadkie w większych zespołach deweloperów zaśmieca serwer CI). Może to być ciągły proces (w idealnym przypadku CI powinien działać przy każdej zmianie gałęzi „Release”) lub może to być noc.

W tym momencie będziesz chciał uruchomić kompilację i uzyskać wykonalny artefakt kompilacji z serwera CI (tj. Coś, co można wdrożyć). Możesz pominąć ten krok, jeśli używasz dynamicznego języka! Po zbudowaniu będziesz chciał uruchomić testy jednostkowe, ponieważ są one podstawą wszystkich automatycznych testów w systemie; prawdopodobnie będą szybkie (co jest dobre, ponieważ celem CI jest skrócenie pętli sprzężenia zwrotnego między programowaniem a testowaniem) i prawdopodobnie nie będą wymagać wdrożenia. Jeśli przejdą pomyślnie, będziesz chciał automatycznie wdrożyć aplikację na serwerze testowym (jeśli to możliwe) i uruchomić wszelkie dostępne testy integracji. Testy integracyjne mogą być zautomatyzowanymi testami interfejsu użytkownika, testami BDD lub standardowymi testami integracyjnymi z wykorzystaniem frameworku testowania jednostkowego (tj. „Jednostka”

W tym momencie powinieneś mieć dość kompleksowe wskazanie, czy kompilacja jest wykonalna. Ostatnim krokiem, który normalnie konfigurowałbym za pomocą gałęzi „Release”, jest automatyczne wdrożenie kandydata do wydania na serwerze testowym, aby dział kontroli jakości mógł przeprowadzić ręczne testy dymu (często odbywa się to w nocy zamiast podczas odprawy, tak aby aby uniknąć zepsucia cyklu testowego). To po prostu daje ludzką wskazówkę, czy kompilacja jest naprawdę odpowiednia do wydania na żywo, ponieważ dość łatwo jest przeoczyć rzeczy, jeśli twój pakiet testowy jest mniej niż wyczerpujący, a nawet przy 100% pokryciu testów łatwo przegapić coś, co możesz „t (nie powinien) testować automatycznie (np. źle ustawiony obraz lub błąd pisowni).

To jest naprawdę połączenie ciągłej integracji i ciągłego wdrażania, ale biorąc pod uwagę, że Agile koncentruje się na szczupłym kodowaniu i automatycznych testach jako procesie pierwszej klasy, chcesz dążyć do uzyskania możliwie jak najbardziej kompleksowego podejścia.

Proces, który nakreśliłem, jest idealnym scenariuszem. Istnieje wiele powodów, dla których możesz porzucić jego część (na przykład gałęzie programistów po prostu nie są możliwe w SVN), ale chcesz dążyć do jak największej ich liczby .

Jeśli chodzi o sposób, w jaki pasuje do tego cykl sprintu Scrum, najlepiej, aby premiery odbywały się tak często, jak to możliwe, i nie pozostawiać ich do końca sprintu, aby uzyskać szybką informację zwrotną na temat tego, czy funkcja (i zbudować jako całość) ) jest wykonalne, ponieważ przejście do produkcji jest kluczową techniką skracania pętli sprzężenia zwrotnego z właścicielem produktu.

Koncepcyjnie tak. Diagram nie zawiera wielu ważnych punktów, takich jak:

1. testów jednostkowych
2. przyrostowe zatwierdzenia
3. inscenizacja jest często wdrażana, produkcja zwykle nie.

Możesz narysować szerszy system dla schematu. Zastanowiłbym się nad dodaniem następujących elementów:

Pokaż swoje dane wejściowe do systemu, które są przekazywane programistom. Nazwij je wymaganiami, poprawkami błędów, historiami lub cokolwiek innego. Ale obecnie Twój przepływ pracy zakłada, że ​​widz wie, w jaki sposób wstawiane są te dane wejściowe.

Pokaż punkty kontrolne wzdłuż przepływu pracy. Kto / co decyduje, kiedy dozwolona jest zmiana na trunk / main / release-branch / etc ...? Jakie kody / projekty są oparte na WNP? Czy istnieje punkt kontrolny, aby sprawdzić, czy kompilacja została uszkodzona? Kto zwalnia z WNP do inscenizacji / produkcji?

Powiązane z punktami kontrolnymi jest określenie, jaka jest twoja metodologia rozgałęziania i jak pasuje do tego przepływu pracy.

Czy jest zespół testowy? Kiedy są zaangażowani lub powiadomieni? Czy w WNP przeprowadzane są automatyczne testy? W jaki sposób awarie są przesyłane z powrotem do systemu?

Zastanów się, jak zamapujesz ten przepływ pracy na tradycyjny schemat blokowy z punktami decyzyjnymi i danymi wejściowymi. Czy udało Ci się uchwycić wszystkie punkty kontaktowe na wysokim poziomie, które są potrzebne, aby odpowiednio opisać przebieg pracy?

Wydaje mi się, że twoje oryginalne pytanie próbuje dokonać porównania, ale nie jestem pewien, w którym aspekcie próbujesz porównać. Ciągła integracja ma punkty decyzyjne, podobnie jak inne modele SDLC, ale mogą znajdować się w różnych punktach procesu.

Używam terminu „Automatyzacja programowania”, aby objąć wszystkie działania związane z automatyczną kompilacją, generowaniem dokumentacji, testowaniem, pomiarem wydajności i wdrażaniem.

„Serwer automatyzacji programowania” ma zatem podobny, ale nieco szerszy zakres zadań niż serwer ciągłej integracji.

Wolę używać skryptów automatyzacji programowania opartych na hakach po zatwierdzeniu, które pozwalają na automatyzację zarówno oddziałów prywatnych, jak i centralnej magistrali programistycznej, bez konieczności dodatkowej konfiguracji na serwerze CI. (Wyklucza to użycie większości gotowych interfejsów GUI serwera CI, o których wiem).

Skrypt po zatwierdzeniu określa, które działania automatyzacji należy uruchomić na podstawie zawartości samego oddziału; albo przez odczyt pliku konfiguracyjnego po zatwierdzeniu w ustalonej lokalizacji w gałęzi, lub przez wykrycie określonego słowa (używam / auto /) jako komponentu ścieżki do gałęzi w repozytorium (z Svn)).

(Łatwiej jest skonfigurować Svn niż Hg).

Takie podejście pozwala zespołowi programistycznemu na większą elastyczność w organizowaniu przepływu pracy, umożliwiając CI wspieranie rozwoju w oddziałach przy minimalnym (prawie zerowym) obciążeniu administracyjnym.

Istnieje pewna seria postów na temat ciągłej integracji na asp.net , które mogą ci się przydać, obejmują one sporo gruntu i przepływów pracy, które pasują do tego, jak wygląda po wykonaniu.

W diagramie nie ma wzmianki o pracy wykonanej przez serwer CI (testy jednostkowe, pokrycie kodu i inne metryki, testy integracyjne lub kompilacje nocne), ale zakładam, że wszystko to obejmuje etap „Continuous Integration server”. Nie jestem jednak pewien, dlaczego skrzynka CI przesuwałaby się z powrotem do centralnego repozytorium? Oczywiście musi otrzymać kod, ale dlaczego miałby kiedykolwiek go odsyłać?

CI jest jedną z tych praktyk zalecanych przez różne dyscypliny, nie jest unikalna dla scrum (lub XP), ale w rzeczywistości powiedziałbym, że korzyści są dostępne dla każdego przepływu, nawet dla nie-zwinnych, takich jak wodospad (może mokro-zwinny?) . Dla mnie kluczowymi zaletami są ciasna pętla zwrotna, dość szybko wiesz, czy kod, który właśnie zatwierdziłeś, działa z resztą bazy kodu. Jeśli pracujesz w sprincie i masz codzienne awarie, możesz odnieść się do statusu lub danych z ostatnich nocy zbudowanych na serwerze CI jest zdecydowanie plusem i pomaga skupić ludzi. Jeśli właściciel produktu widzi status kompilacji - duży monitor we wspólnym obszarze pokazujący status twoich projektów kompilacji - to naprawdę zacieśniłeś tę pętlę sprzężenia zwrotnego. Jeśli Twój zespół programistów popełnia często (więcej niż raz dziennie, a najlepiej częściej niż raz na godzinę), szanse na wystąpienie problemu z integracją, którego rozwiązanie zajmuje dużo czasu, są zmniejszone, ale jeśli tak, to oczywiste, że wszystko i możesz podjąć wszelkie niezbędne środki, na przykład wszyscy zatrzymują się, aby poradzić sobie z uszkodzoną wersją. W praktyce prawdopodobnie nie trafisz w wiele nieudanych kompilacji, które zajmują więcej niż kilka minut, aby dowiedzieć się, czy często się integrujesz.

W zależności od zasobów / sieci warto rozważyć dodanie różnych serwerów końcowych. Mamy kompilację CI, która jest wyzwalana przez zatwierdzenie repozytorium i zakładając, że buduje i przekazuje wszystkie swoje testy, a następnie jest wdrażana na serwerze programistycznym, aby deweloperzy mogli upewnić się, że gra dobrze (możesz dołączyć tutaj testowanie selenu lub innego interfejsu użytkownika? ). Nie każde zatwierdzenie jest jednak stabilną wersją, więc aby wywołać kompilację na serwerze pomostowym, musimy oznaczyć wersję (używamy mercurial), którą chcemy zbudować i wdrożyć, ponownie wszystko to jest zautomatyzowane i uruchamiane po prostu przez zatwierdzenie określonego etykietka. Przejście do produkcji jest procesem ręcznym; możesz to tak proste, jak wymuszenie kompilacji, sztuczka polega na tym, aby wiedzieć, której wersji / kompilacji chcesz użyć, ale jeśli odpowiednio oznaczysz wersję, serwer CI może sprawdzić poprawną wersję i zrobić wszystko, co jest potrzebne. Możesz użyć MS Deploy do zsynchronizowania zmian na serwerze (serwerach) produkcyjnym lub do spakowania go i umieszczenia pliku zip w miejscu, w którym administrator może wdrożyć ręcznie ... zależy to od tego, jak dobrze się z tym czujesz.

Oprócz wersji do góry powinieneś również rozważyć, jak możesz sobie poradzić z awarią i przejść do wersji. Mamy nadzieję, że tak się nie stanie, ale na twoich serwerach mogą zostać wprowadzone pewne zmiany, co oznacza, że ​​to, co działa w UAT, nie działa w środowisku produkcyjnym, więc wypuszczasz zatwierdzoną wersję i kończy się ona niepowodzeniem ... zawsze możesz przyjąć podejście, które identyfikujesz błąd, dodaj trochę kodu, zatwierdzaj, testuj, wdrażaj do produkcji, aby go naprawić ... lub możesz zakończyć dodatkowe testy wokół automatycznego wydania do produkcji, a jeśli to się nie powiedzie, to automatycznie cofa się.

CruiseControl.Net używa xml do konfigurowania kompilacji, TeamCity używa kreatorów, jeśli chcesz uniknąć specjalistów w zespole, to złożoność konfiguracji xml może być czymś innym, o czym należy pamiętać.

Po pierwsze, zastrzeżenie: Scrum jest dość rygorystyczną metodologią. Pracowałem dla kilku organizacji, które próbowały używać Scruma lub podejść podobnych do Scruma, ale żadna z nich tak naprawdę nie była bliska zastosowania pełnej dyscypliny w całości. Z moich doświadczeń jestem entuzjastą Agile, ale (niechętnie) Scrum-sceptycznym.

Jak rozumiem, Scrum i inne metody Agile mają dwa główne cele:

• Pierwszym z nich jest zapewnienie wyraźnego mechanizmu zarządzania ryzykiem i ciągłego odkrywania ryzyka.
• Drugim jest zapewnienie ustrukturyzowanego mechanizmu komunikacji z zainteresowanymi stronami, odkrywania wymagań i zarządzania wymaganiami.

Pierwszy cel (zarządzanie ryzykiem) osiąga się poprzez iteracyjny rozwój; szybkie popełnianie błędów i lekcje uczenia się, co pozwala zespołowi na budowanie zrozumienia i zdolności intelektualnych w celu zmniejszenia ryzyka i przejścia do rozwiązania o zmniejszonym ryzyku z „surowym” rozwiązaniem niskiego ryzyka już w torbie.

Automatyzacja rozwoju, w tym ciągła integracja, jest najważniejszym czynnikiem decydującym o powodzeniu tego podejścia. Odkrywanie ryzyka i uczenie się lekcji musi być szybkie, wolne od tarcia i wolne od zagmatwanych czynników społecznych. (Ludzie uczą się DUŻO szybciej, gdy jest to maszyna, która mówi im, że są w błędzie, a nie inny człowiek - ego tylko przeszkadzają w nauce).

Jak zapewne możesz powiedzieć - jestem także fanem testów opartych na testach. :-)

Drugi cel ma mniej wspólnego z automatyzacją programowania, a więcej z Czynnikami ludzkimi. Trudniej jest go wdrożyć, ponieważ wymaga on zakupu od frontu firmy, który raczej nie zauważy potrzeby formalności.

Automatyzacja rozwoju może mieć tutaj rolę, ponieważ automatycznie generowana dokumentacja i raporty z postępu mogą być wykorzystywane do ciągłego aktualizowania interesariuszy spoza zespołu programistów o postępie, a do przekazywania informacji o postępach można użyć grzejników informacyjnych pokazujących status kompilacji i zestawy testów pozytywnych / negatywnych. na temat rozwoju funkcji, pomagając (miejmy nadzieję) wesprzeć proces komunikacji Scrum.

Podsumowując:

Schemat użyty do zilustrowania pytania obejmuje tylko część procesu. Jeśli chciałbyś studiować agile / scrum i CI, argumentowałbym, że ważne jest rozważenie szerszych aspektów społecznych i ludzkich czynników tego procesu.

Muszę zakończyć od uderzenia w ten sam bęben, który zawsze robię. Jeśli próbujesz wdrożyć sprawny proces w projekcie z prawdziwego świata, najlepszym predyktorem twojej szansy na sukces jest poziom automatyzacji, który został wdrożony; zmniejsza tarcie, zwiększa prędkość i toruje drogę do sukcesu.