Przewodnik: Zarządzanie wersjami oprogramowania dla małych zespołów

Formalizacja procesu zarządzania wydaniami (jeśli istnieje)

W niektórych konfiguracjach zespołów, zwłaszcza tych, które znajdują się w startupach, nie ma DevOps ani inżynierów infrastruktury, którzy zapewnialiby wsparcie przy wydawaniu nowej wersji produktu.

Co więcej, w przeciwieństwie do dużych firm biurokratycznych ze zdefiniowanymi formalnymi procesami, CTO lub Head of Software Development team w startupie często nie zdaje sobie sprawy ze złożoności procesu zarządzania wydaniami oprogramowania; kilku programistów w firmie może być świadomych skomplikowanych szczegółów procesu, ale nie wszyscy. Jeśli ta wiedza nie zostanie dokładnie udokumentowana , wierzę, że może to spowodować zamieszanie.

W tym artykule postaram się podać kilka wskazówek, jak sformalizować proces wydawania, szczególnie z punktu widzenia dewelopera.

Wejdź na listę kontrolną wydania oprogramowania

Być może znasz ideę listy kontrolnej dla niektórych operacji, zgodnie z Manifestem listy kontrolnej , książką Atula Gawande. Uważam, że formalny proces wydania (podobnie jak wiele innych zadań w świecie tworzenia oprogramowania) zapewnia programistom możliwość zaimplementowania tego protokołu. Lista kontrolna procesu wydania powinna być przechowywana w udostępnionym dokumencie, najlepiej w formie wspólnej wiki lub arkusza kalkulacyjnego na Dysku Google.

Udostępniając ten ważny dokument zespołowi i przyznając uprawnienia do edycji, każdy członek ma dostęp do formalnie zdefiniowanego procesu wydania. To pozwala im zrozumieć, jak działa ten proces. Co więcej, po dyskusjach z innymi członkami zespołu, umożliwia zespołowi ulepszanie go od czasu do czasu. Powinno to zapewnić przejrzystość i umożliwić całemu zespołowi dostęp w czasie rzeczywistym do tego, co dzieje się podczas wydania, jakie kroki zostały wykonane i przez kogo.

Patrząc na ten arkusz kalkulacyjny, interesariusze mogą zdecydować, czy wybrać opcję „GO” a „NO GO”, w oparciu o wyniki kroków. Na przykład, jeśli test warunków skrajnych nie powiedzie się w środowisku testowym, na podstawie zdarzenia kierownik projektu może zdecydować o odwołaniu wydania produkcyjnego.

Sugerowane kroki do użycia jako podkładu

W tej sekcji zaproponuję kilka kroków, które możesz wykorzystać do zbudowania własnej listy kontrolnej dla procesu wydania. Niektóre z tych kroków w żadnym wypadku nie są obowiązkowe . Każda aplikacja jest inna i każda organizacja działa w inny sposób, więc możesz swobodnie dostosowywać się i wprowadzać zmiany, które będą lepiej pasować do Twojego przepływu pracy.

1. Utwórz gałąź wydania

Prawdopodobnie znasz koncepcję przepływu pracy Git lub ideę gałęzi wydań, temat, który został wyjaśniony w poprzednim poście na blogu.

Idealnie powinieneś mieć co najmniej trzy gałęzie:

• master : powinien odzwierciedlać aktualny stan środowiska produkcyjnego. Każdy nowy commit na master powinien zawierać tylko nowe wydanie.
• development : ta gałąź powinna zawierać ukończone (i przetestowane) nadchodzące funkcje. Często tworzy się osobną gałąź dla każdej funkcji, a następnie scala ją, aby rozwijać się, gdy funkcja jest gotowa.
• release : gałęzie wydania to zbiór zatwierdzeń, które są gotowe do wysłania do produkcji, plus kilka dodatkowych drobnych poprawek związanych z wydaniem.

Zauważ, że gałęzie wydania powinny zostać usunięte po zakończeniu wydania, dlatego te gałęzie są tworzone i niszczone przez cały czas, w przeciwieństwie do master lub development , które zawsze są takie same.

Aby utworzyć nową gałąź wydania , z gałęzi deweloperskiej w terminalu git, wpisz:

$ git checkout -b release/xyz

Wygodnie jest użyć konwencji nazewnictwa, takiej jak ta zdefiniowana powyżej, zastępując xyz numerem wersji major.minor.patch zgodnie z własnymi potrzebami (jest to zasada, którą powinieneś zdefiniować w swoim zespole i się jej trzymać).

Ważne jest również, aby powiedzieć, że jeśli kodujesz poprawki błędów w gałęzi wydania, nie powinieneś zapominać o ich ponownym scaleniu w celu development . Głównym celem gałęzi wydania jest uzyskanie podglądu stanu, w jakim aplikacja powinna się zachowywać po przejściu do produkcji.

2. Wersja wypukła

Następnym krokiem byłoby podbicie (zmodyfikowanie lub zwiększenie) numeru wersji w gałęzi wydania .

Należy otworzyć plik AndroidManifest.xml / package.json / pom.xml / lub gdziekolwiek wersja aplikacji jest przechowywana w projekcie (YMMV), zaktualizować numer wersji, a następnie zatwierdzić zmiany w gałęzi bieżącego wydania .

Aktualizacja numeru wersji jest ważna z dwóch powodów.

Po pierwsze, możesz śledzić i mapować funkcje wprowadzone w każdej wersji, a po drugie, będziesz świadomy używanej wersji, jeśli będą musieli rozwiązać problem lub skontaktować się z Tobą w celu uzyskania pomocy. Jeśli tworzysz aplikację mobilną, numer wersji, którą aktualizujesz w tym kroku, jest zwykle wyświetlany po stronie użytkownika, w sekcji Informacje lub w Google Play lub Apple App Store . Ten krok jest również dobrą okazją do aktualizacji zależnej od środowiska -pliki konfiguracyjne (chociaż sugerowałbym przechowywanie ich w osobnym repozytorium), takie jak wskazywanie gałęzi na produkcyjną bazę danych lub inne poprawki potrzebne w procesie budowania.

Na koniec zaleca się, aby wypchnąć gałąź wydania do źródła, aby była dostępna dla innych programistów:

$ git push -u origin release/xyz

3a. Scal gałąź wydania do mastera i otaguj ją

Tylko gałąź master powinna być wdrożona do produkcji, dlatego w tym kroku musimy połączyć gałąź release z master .

 $ git checkout master $ git merge --no-ff release/xyz $ git push

Flaga --no-ff jest opcjonalna, jednak jej użycie jest zalecane w celu wymuszenia utworzenia nowego obiektu commit, nawet jeśli scalanie można zakończyć przy użyciu techniki fast-forward.

Następnie nadszedł czas, aby oznaczyć wydanie w gałęzi master :

$ git tag -a xyz -m 'description of new version, features or fixes included'

Tagi są przydatne, ponieważ utrwalasz ten konkretny punkt w historii w repozytorium git i możesz wrócić później, aby odtworzyć oddzielną gałąź z określonego tagu.

3b. Użyj pull request, aby scalić gałąź wydania

Inną często stosowaną alternatywą jest użycie żądania ściągnięcia w celu scalenia gałęzi wydania z master .

Takie podejście ma wiele zalet. Powstaje nowa przestrzeń do współpracy, którą zespół może wykorzystać do omówienia różnych kwestii związanych z wydaniem. Ten punkt to dobry moment, aby dodać dodatkową bramkę do włączenia procesu przeglądu kodu, jednocześnie mając więcej gałek ocznych do monitorowania kodu, który zostanie wprowadzony, i omówienia potencjalnych modyfikacji.

Niektóre narzędzia, które umożliwiają implementację pull requestów do przepływów pracy, to GitHub, Bitbucket i GitLab (żądanie scalenia, jak to się nazywa w tym drugim). Za pomocą tych narzędzi nie wpisujesz poleceń git ręcznie, zamiast tego używasz interfejsu internetowego do ustawienia gałęzi źródłowej ( release ) i gałęzi docelowej ( master ), a następnie dodajesz jednego lub więcej recenzentów, z których wszyscy będą móc pisać komentarze w tekście do tych nowych zmian, sugerować ulepszenia i tak dalej.

Gdy wszyscy recenzenci zatwierdzą żądanie ściągnięcia, możesz automatycznie scalić zmiany z wzorcem , naciskając przycisk w interfejsie użytkownika.

4. Wdróż Master w środowisku produkcyjnym

Na tym etapie dobrą praktyką jest, aby tester w zespole wykonał test dymny (można to zdefiniować na osobnej liście kontrolnej) przed wdrożeniem aplikacji. Dobrą sugestią jest wdrożenie gałęzi master w osobnym środowisku testowym. Tester może następnie wykonać kilka podstawowych czynności, aby upewnić się, że nic nie poszło nie tak po scaleniu najnowszej wersji. Sposób przeprowadzenia testu dymu wykracza poza zakres tego artykułu, ale w sieci można znaleźć wiele materiałów na ten temat. Wynik testu dymu można zintegrować z listą kontrolną/arkuszem kalkulacyjnym wydania, dokumentując wszystko, co poszło nie tak.

W tym momencie jesteś gotowy do wdrożenia zmian i wprowadzenia ich w życie. Śmiało i wdróż gałąź master . Ten krok będzie zależał od używanego stosu infrastruktury. Może to obejmować połączenie z instancją Amazon EC2 w celu przesłania aplikacji, przekazanie do pilota Heroku lub połączenie przez ssh z serwerem VPS w celu skopiowania nowej wersji lub dowolny inny proces.

Po przesłaniu aplikacji upewnij się, że została wdrożona pomyślnie i działa zgodnie z oczekiwaniami.

5. Połącz z powrotem w Develop and Delete Release Branch

Teraz wydanie jest prawie ukończone, będziesz chciał połączyć gałąź wydania z rozwojem , zaktualizować numer wersji w tym ostatnim i przenieść wszystkie poprawki błędów do głównej gałęzi rozwojowej:

 $ git checkout develop $ git merge release/xyz

Teraz pora na usunięcie gałęzi wydania :

$ git branch -d release/xyz

6. Generowanie dziennika zmian

W katalogu głównym projektu powinien znajdować się plik o nazwie CHANGELOG.md (lub odpowiednik), w którym należy dodawać nowy wpis za każdym razem, gdy pojawia się nowe wydanie, aby udokumentować wszystko, co jest w nim zawarte, takie jak poprawki błędów, nowe funkcje, znane problemy i wszelkie inne istotne informacje w postaci informacji o wersji. Jest to bardzo przydatne dla użytkowników i współtwórców , aby zobaczyć, jakie zmiany zostały wprowadzone między każdym wydaniem (lub wersją) projektu.

Wpis w dzienniku zmian zawiera datę, numer wersji i kilka uwag o wydaniu. Wpisy powinny być ułożone w odwrotnej kolejności chronologicznej. Oto prosty szablon, którego używałem, który możesz dostosować do swojego projektu:

 <app's name or component released> <version xyz> | <date> <developer's name in charge of release> | <developer's email> Features: * <ticket/issue number>: <ticket/issue summary> (<link to issue tracker>) * ... Bugs fixed: * <ticket/issue number>: <ticket/issue summary> (<link to issue tracker>) * ... Enhancements: * <ticket/issue number>: <ticket/issue summary> (<link to issue tracker>) * ... Optional: known issues plus other release notes.

Ponadto ten krok można całkowicie zautomatyzować, albo zakodując podstawowy skrypt, który przemierza dziennik git i automatycznie generuje wpis dziennika zmian, albo używając narzędzia, które robi to samo, takiego jak:

• Github Changelog Generator, autorstwa skywinder,
• ReadmeGen autorstwa fojuth
• github-zmiany, autorstwa lalitkapoor

Pamiętaj jednak, że uzyskany stopień automatyzacji jest wprost proporcjonalny do ścisłości formatu komunikatu zatwierdzenia. Uważam, że zawsze dobrą praktyką jest uzgadnianie z zespołem określonego formatu komunikatów dotyczących commitów. Postępując zgodnie z wytycznymi dotyczącymi stylu komunikatów o zatwierdzeniu, będą one łatwiejsze do przeanalizowania, a tym samym bardziej prawdopodobne, że będziesz w stanie zautomatyzować generowanie dziennika zmian.

7. Komunikuj się z interesariuszami

W tym miejscu zwykle wykonujesz niektóre z następujących czynności:

• Poinformuj zespół za pomocą wewnętrznego narzędzia do przesyłania wiadomości (np. Slack), że nowa wersja została ukończona. Zalecam utworzenie nowego kanału (np.: #releases ) wyłącznie w celu komunikowania wydarzeń związanych z wydaniem. Łatwo jest dodać haki w kanale Slack, aby opublikować wiadomość po podjęciu akcji.
• Alternatywnie, wyślij e-mail do udziałowców z linkiem do dziennika zmian lub załączonym plikiem dziennika zmian.
• Napisz post na blogu (jeśli masz blog dotyczący swojej aplikacji lub produktu) lub tweeta.

Więcej działań można podjąć w zależności od charakteru Twojej organizacji. Ważne jest, aby nie zapomnieć o poinformowaniu, że dostępna jest nowa wersja Twojego produktu.

8. Pielęgnacja trackera problemów

Po wykonaniu wydania prawdopodobnie będziesz musiał zaktualizować status niektórych swoich zgłoszeń, aby śledzić poprawki błędów lub funkcje, które są obecnie w produkcji. Generalnie wiąże się to ze zmianą niektórych tagów (w przypadku małych projektów używam tagu „ release-pending ”, który usuwam po zakończeniu wydania).

Jeśli używasz kamieni milowych dla każdej nowej wersji, prawdopodobnie będziesz musiał zaktualizować ich status lub oznaczyć je jako ukończone. Niektóre narzędzia do śledzenia problemów pozwalają nawet zaplanować wydanie i dopasować je do sprintów, śledzić, czy błąd blokuje wydanie i inne przydatne informacje.

Wszystko zależy od tego, jak korzystasz z narzędzia. Chcę tylko zaznaczyć, że zadanie aktualizacji informacji w narzędziu do śledzenia problemów powinno być uwzględnione na liście kontrolnej wydania.

Informacje o automatyzacji procesu wydania

Czytelnik mógł zauważyć, że oprócz opisanego powyżej kroku dziennika zmian, wiele z wyżej wymienionych kroków można również zautomatyzować.

Możliwość zautomatyzowania niektórych części procesu wydania jest ogromną wygraną i pozwala zaoszczędzić sporo czasu. Proponuję tworzyć skrypty lub zastanawiać się, jak zautomatyzować poszczególne kroki, a następnie pracować nad ciągłym celem dostarczania. Ciągłe dostarczanie może zmniejszyć ryzyko, obniżyć koszty i skrócić czas, jaki programiści muszą poświęcić na zarządzanie wydaniem. W związku z tym będziesz mógł częściej wypuszczać i być bardziej produktywnym pod względem godzin przeznaczonych na rozwój.

Świętym Graalem firm DevOps jest możliwość uruchomienia nowej wersji poprzez naciśnięcie przycisku (lub uruchomienie polecenia), które uruchomiłoby proces wydania automatycznie, lub nawet lepiej, system, który wypuściłby nową wersję oprogramowania w wyznaczonym czasie. Oczywiście jest to trudne do osiągnięcia, ponieważ trzeba również wiele zautomatyzować procesu testowania, ale nie jest to niemożliwe.

Przyjmowanie najlepszych praktyk

W tej sekcji opiszę kilka zalecanych praktyk, które uważam za wygodne, albo w celu usprawnienia procesu wydawania, albo w celu podjęcia środków bezpieczeństwa na wypadek, gdyby coś poszło nie tak.

Znajdź najbardziej odpowiedni dzień na premierę

Aplikacje, nad którymi pracuję, wypuszczam zwykle w czwartki, od południa do końca pracy.

Jeśli pracujesz od poniedziałku do piątku, nie jest dobrym pomysłem uruchamianie w piątek. Jeśli coś się zepsuje po wydaniu, nie będziesz miał czasu na naprawę do poniedziałku (chyba że chcesz pracować w weekend). Dlatego wygodniej jest robić wydania w czwartek, ponieważ masz piątek na monitorowanie nowej wersji po wdrożeniu, naprawienie wszelkich problemów lub wycofanie.

Inną ważną rzeczą, o której należy wspomnieć, jeśli zarządzasz aplikacją internetową, jest znajomość strefy czasowej, w której znajduje się większość użytkowników. Powinieneś ustawić czas na zwolnienie w okresie niskiego natężenia ruchu, aby zminimalizować potencjalne szkody, jeśli coś zawiedzie. Czasami może to być trudne, gdy twoja baza użytkowników jest rozproszona na całym świecie, ale tak czy inaczej, powinieneś zrobić rozeznanie i zdecydować się na najlepszy czas.

Utwórz kopię zapasową bazy danych przed nową wersją

Jeśli nie masz zaplanowanych okresowych kopii zapasowych bazy danych, zdecydowanie sugeruję, abyś dodał krok w procesie wydania, aby wykonać kopię zapasową przed rozpoczęciem wydania.

Wdrażanie etapowe

Czy zastanawiałeś się kiedyś, dlaczego gdy wydawca ogłasza, że ​​wprowadził nową funkcję, potrzeba dni, a nawet tygodni, zanim ta funkcja będzie dostępna w Twoim telefonie? Dzieje się tak, ponieważ wiele firm korzysta z wdrażania etapowego.

Facebook robi to od dłuższego czasu. Testuje nową funkcję na pięciu lub 10 procentach swoich użytkowników, stopniowo zwiększając ją, aż osiągną 100 procent bazy użytkowników. Podczas fazy wdrażania etapowego musisz uważnie przyjrzeć się opiniom użytkowników i raportom o awariach. Dzięki tym informacjom możesz odroczyć wydanie lub naprawić błędy, zanim wpłyną one na każdego użytkownika.

W Konsoli programisty Androida jest fajne narzędzie, które implementuje etapowe wdrażanie aplikacji na Androida.

Ciągła integracja

Ciągła integracja to praktyka warta objęcia z wielu powodów. Po pierwsze, pozwala na wczesne wykrywanie błędów, zwiększając wskaźnik udanych wydań. Po drugie, jest to pierwszy logiczny krok przed wdrożeniem Continuous Delivery i pełnej automatyzacji, jak opisano wcześniej.

Martin Fowler jest wielkim zwolennikiem Ciągłej Integracji. Opisuje ogromną liczbę korzyści, które można dodać do procesu wydawania, stosując tę ​​praktykę. To obszerny temat i jest na ten temat wiele książek i wpisów na blogu, a wspominam o tym tutaj, ponieważ wierzę, że da ci to znacznie więcej pewności w twoich działaniach. Wśród wielu zalet korzystania z CI znajdziesz: mniejsze ryzyko, zwiększoną widoczność, aby wiedzieć, co działa, a co nie, wcześniejsze wykrywanie błędów, zwiększoną częstotliwość wdrożeń i wiele innych.

Punktem wyjścia do wdrożenia CI jest utworzenie „serwera ciągłej integracji”; kilka fajnych narzędzi do wypróbowania to: CruiseControl, Bamboo, Jenkins i Travis.

Exitlude: wszystko się ułoży

Agresywnie wszyscy bronimy roli, którą gramy Niestety, nadchodzą czasy, aby wysłać cię w drogę Widzieliśmy to wszystko, ogniska zaufania, błyskawiczne powodzie bólu To naprawdę nie ma znaczenia, nie martw się, to będzie wszystko ćwiczy

Exitlude, Zabójcy

Podsumowując, powiedziałbym, że bardzo ważne jest, aby mieć dobrze zdefiniowany proces wydawania aplikacji, niezależnie od jej złożoności, bazy użytkowników lub tego, jak mała jest Twoja organizacja.

Jeśli nie, sugeruję, abyś zaczął myśleć o kilku podstawowych krokach, korzystając z tego przewodnika i innych podobnych, i przeprowadzić burzę mózgów ze swoim zespołem, aby opracować pierwszą wersję roboczą. Wypróbuj go w następnym wydaniu, a następnie powtórz. W końcu zbudujesz swój własny proces wydawania.

Następnie zacznij myśleć o tym, jak zautomatyzować części procesu . Pomyśl o obszarach, które można poprawić. Poznaj sposoby skrócenia czasu wydania przez wprowadzenie niewielkich optymalizacji. Twoim ostatecznym celem powinna być automatyzacja; jednak nie planuj tego od samego początku, bo poniesiesz porażkę próbując tak dużego skoku. Jak w przypadku każdego procesu, lepiej jest go ulepszać stopniowo.

Czy masz jakieś inne sztuczki lub wskazówki, których używasz do uruchamiania nowych wersji swojej aplikacji? Jeśli tak, daj mi znać. Nie pochodzę ze świata DevOps, jestem tylko programistą, który akurat jest dość zorganizowany i uporządkowany, ale w porównaniu z wieloma weteranami, nadal jestem w tym zakresie nowicjuszem, więc śmiało możesz skomentować lub skontaktować się ze mną, jeśli masz coś do dodania.