[Screencast] Tworzenie publicznego repo na gitlabie wraz z pipeline’ami

Chcieliśmy pokazać jak proste jest stworzenie darmowego repozytorium wraz z Continuous Integration. Zrobiliśmy to używając GitLab CI/CD pipelines (GitHub też już ma dobre mechanizmy CI – GitHub Actions). GitLab jest po prostu bardziej rozpowszechoniony w firmach.

Pokazujemy również:

  • skorzystanie z gotowych zdefiniowanych template’ów CI dla popularnych języków
  • przykład Merge Request i merge do master‚a
  • przyklepanie Merge Requestu (Code Review).
  • wiele Merge Requestów jednocześnie i jak się gitlab zachowa
  • kilka ustawień usprawniających Merge Requesty (np Fast-forward only)

Odcinek był nagrywany na 2 sesje i niestety w połowie delikatnie ucina nam rodzielczość więc nie zobaczycie w całości górnej i lewej belki :/ ale poprawiła się jakość dźwięku 🙂

Montaż: Adrian Wasielewski

6 Comments on “[Screencast] Tworzenie publicznego repo na gitlabie wraz z pipeline’ami

  1. Spoko macie screencasty. Mam tylko jedno pytanie. Ustawiacie „Fast-forward only”, a co jeśli musicie/chcecie cofnąć merga? Załóżmy, że mergujecie jakiegoś brancha i po krótkim czasie okazuje się, że jednak ten branch nie powinien zostać wdrożony w tym terminie. Commit mergujący pozwala zrobić łatwo reverta takiego merga. Z opcją FF nie jest to możliwe. trzeba ręcznie revertować każdego commita, co jest czasem prawie niemożliwe. Takie sytuacje często mi się zdarzały w jednym dużym projekcie.

    Oczywiście zdaję sobie sprawę, że to też może zależeć od modelu pracy. I też można ten problem obchodzić na wiele sposobów. Ale revert commita mergującego jest raczej najprostszą opcją.

  2. Gdy robi się MR do mastera to jest to najczęśniej jeden commit. W trakcie pracy tych commitów mogło być spokojnie kilkadziesiąt, ale przed pushem robimy squash do jednego. Jeśli później były poprawiki po Code Review to też trzeba je squash do jednego commita.

    Wtedy do revert jest tylko jeden commit z właściwą jedną funkcjonalnością.
    Polecam ten model.

    • Ok, dzięki za odpowiedź. Zapomniałem napisać, że nie używałem za bardzo Gitlaba, a zwykle pracowałem na Gerricie i tam to wygląda zupełnie inaczej. Branche mają wiele commitów(każdy z osobna przechodzi review) i te commity są mergowane bez squasha to master.

  3. Domyśliłem się, że właśnie tak robicie. Jak dla mnie wtedy historia jest mało czytelna bo zawiera mnóstwo zmieniających się rzeczy, które po jakimś czasie są nieistotne. IMHO nie jest istotne jak powstawał dany feature czy zmieniała się koncepcja i jak poszło CR, a ważne jest jak to ostatecznie wylądowało na masterze.

    • No właśnie czasem jest istotne jak powstał dany kawałek kodu, kto go zrobił i jak modyfikował(i w tym modelu w którym ja pracowałem można to wszystko odtworzyć). Ale tak naprawdę musiałbym trochę popracować z Gitlabem, żeby konkretnie powiedzieć czy w danym przypadku takie podejście ma sens. moim zdaniem oba podejścia mają swoje wady i zalety 😉

  4. Cześć. Dzięki za zrobienie tego video! Czy możecie napisać kilka słów po co wogóle potrzebny jest taki pipeline, gdzie należy go zastosować?

Odpowiedz na Krzysztof Morcinek Anuluj pisanie odpowiedzi

Wprowadź swoje dane lub kliknij jedną z tych ikon, aby się zalogować:

Logo WordPress.com

Komentujesz korzystając z konta WordPress.com. Wyloguj /  Zmień )

Zdjęcie na Google

Komentujesz korzystając z konta Google. Wyloguj /  Zmień )

Zdjęcie z Twittera

Komentujesz korzystając z konta Twitter. Wyloguj /  Zmień )

Zdjęcie na Facebooku

Komentujesz korzystając z konta Facebook. Wyloguj /  Zmień )

Połączenie z %s