Dzięki szkoleniu "(Nie-)Techniczny PM I" zrozumiesz naturę projektów informatycznych oraz enigmatyczny świat programistów, poczujesz się swobodnie w rozmowie z technicznym klientem lub szefem, podniesiesz swoje notowania w firmie oraz rozszyfrujesz o czym rozmawiają developerzy.
Jeśli:
zamierzasz rozpocząć swoją przygodę w IT w roli project managera lub scrum mastera, a nie posiadasz doświadczenie technicznego,
chcesz poznać proces wytwarzania oprogramowania, a nigdy nie napisałeś/-aś linijki kodu,
rozmawiając z programistami, chcesz czuć się swobodnie i rozumieć ich język,
nie posiadasz wykształcenia technicznego, a otaczają Cię ludzie techniczni,
chcesz poznać zagadnienia techniczne w jasny i zrozumiały sposób,
to szkolenie "(Nie-)Techniczny PM” jest dla Ciebie!
Podczas serii szkoleń online w usystematyzowany sposób przedstawię Ci zagadnienia techniczne, które pozwolą Ci zrozumieć język programistów i testerów oraz wyzwania, z którymi zmagają się
w codziennej pracy. Zdobyta wiedza przyda Ci się również podczas przyszłych rozmów rekrutacyjnych :)
Jeśli jakiś pakiet wykorzystujesz tylko podczas tworzenia aplikacji to powinieneś go dodać jako zależność deweloperską - "development dependency" (to spowoduje, że użytkownicy Twojej aplikacji (lub pakietu) nie będą instalować takiego pakietu w wersji produkcyjnej). Na przykład, gdy chcesz skorzystać z popularnej biblioteki eslint (jest to tzw. linter) to powinieneś wywołać NPM następująco:
npm install eslint --save-dev
W efekcie dostaniesz nowy wpis w pliku package.json Twojej aplikacji:
"devDependencies" : { "eslint" : "^4.12.1" }
Jeszcze nie tak dawno temu tworzony przez grupy programistów kod zapisywany był lokalnie, a następnie przenoszony za pomocą dyskietek lub umiejscawiany na serwerach FTP. Wówczas konieczne było jego metodyczne i żmudne porównywanie linijka po linijce – zwykle zadanie to przypadało integratorowi.
Praca ta była niesamowicie czaso- i pracochłonna, mało efektywna, a także dość ryzykowna. Nie trudno się domyślić, z jakimi problemami możemy mieć do czynienia podczas pracy wielu specjalistów na tych samych plikach. Do kluczowych niedogodności możemy zaliczyć problemy z synchronizacją tychże plików, błędami związanymi z ich zgodnością, brakiem usystematyzowania, czy marginalna kontrola nad procesem twórczym i panującym wszechobecnym chaosem.
Szczęśliwie, obecnie niemal każdy – nawet pojedynczy – programista pracuje z tym niezwykle ważnym i fundamentalnym narzędziem każdego dewelopera, jakim jest repozytorium kodu. Poniżej pokrótce prezentujemy przegląd najpopularniejszych systemów do utrzymywania kodu.
Historyczny przegląd systemów do utrzymywania kodu
Na początku był CVS
Pierwszym repozytorium kodu był CVS (ang. Concurrent Versions System). Był to system oparty na licencji GPL służący do pracy z plikami w zapisie elektronicznym CVS w architekturze klient-serwer. System powstał w 1986 roku. Technologi zarzucano wiele wad, wynikających głównie z wieku dziecięcego repozytorium. Możemy do nich zaliczyć brak wersjonowania dla zmian nazw oraz usuwania plików, zajmowania sporej ilości miejsca przez tworzone nowe gałęzie, czy brak wsparcia dla rozproszonego systemu kontroli wersji.
Później powstał SVN
System Subversion (SVN) był następcą repozytorium CVS. Ten system kontroli wersji powstał na licencji Apache i stanowił otwarte oraz wolne oprogramowanie, które w założeniu miało wyeliminować błędy i problemy, z którymi borykał się CVS. SVN oferował dedykowany serwer, możliwość szybkiego tworzenia gałęzi i znaczników, pełny podgląd historii zmian nazw katalogów i plików, a także dodał kilka funkcjonalności i usprawnień ułatwiających i przyśpieszających pracę.
Następnie zrodziła się platforma GIT
Pierwsza wersja GIT wydana została w 2005 roku. Jest to rozproszony system kontroli wersji oparty na licencji GNU GPL i stworzony przez twórcę jądra Linuxa – Linusa Torvaldsa. Do kluczowych cech platformy GIT możemy zaliczyć możliwość pracy offline, świetne wsparcie dla rozgałęzionych procesów tworzenia oprogramowania, wsparcie dla protokołów sieciowych: HTTP(S), FTP, rsync, czy SSH, wydajną i przyjemną pracę z dużymi projektami. Poza tym GIT wyeliminował wiele niedociągnięć systemu SVN i zapewnił o wiele dynamiczniejszą pracę z repozytorium kodu, stąd też staje się on coraz popularniejszym systemem do utrzymywania kodu.
GIT zapoczątkował platformy GITLAB, GITHUB i Bitbucket
NA podstawie platformy GIT powstały dwa niezależne narzędzia. Pierwszym z nich był GITHUB. GITHUB to platforma repozytorium w formie platformy hostingowej opartej na systemie GIT. Została uruchomiona w 2008 roku przez Toma Prestona-Wernera, Chrisa Wanstratha i PJ Hyatta. Obecnie jest to największy serwer repozytoryjny utrzymujący ponad 38 milionów projektów. GITLAB został zapoczątkowany przez Valerego Sizova i Dimitriya Zaporozhetsa w 2011 roku i jest to jedyny projekt typu open source.
Bitbucket został stworzony przez australijski startup w 2008 roku. Początkowo wspierał on wyłącznie projekty Mercurial, jednak w 2010 roku został przejęty przez Atlassian i rok później rozpoczął wspieranie hostingu GIT. Obecnie usługa koncentruje się wyłącznie na nim i świetnie integruje się z innymi usługami Atlassian. Głównym targetem Bitbucket jest rynek enterprise.
Każde z trzech omawianych narzędzi oferuje podobne podstawowe funkcjonalności, takie jak: przegląd kodu, tracking problemów, wsparcie dla Markdown, dwuetapowe uwierzytelnianie, snippety, zewnętrzne integracje, funkcjonalny interfejs API, hostowanie statycznych stron internetowych, czy zaawansowany system zarządzania usprawnieniami.
Darmowe plany cenowe platformy GITLAB, GITHUB i Bitbucket
Każda z usług oferuje darmowy plan z podstawowymi funkcjonalnościami. Poniżej prezentujemy ofertę każdej z omawianych usług.
Darmowy plan GITHUB’a pozwala na przechowywanie nieograniczonej liczby publicznych repozytoriów z możliwością ich klonowania i forkowania. Nie ogranicza ilości dostępnego miejsca na dysku, jednak projekty w darmowym planie nie mogą przekraczać 1 GB, a pojedyncze pliki nie mogą ważyć więcej niż 100 MB.
Bitbucket umożliwia współdzielenie repozytorium między pięcioosobowym zespołem. Nie ogranicza ilości projektów, jednak repozytoria nie mogą przekraczać rozmiaru 1 GB.
Darmowy plan hostingowy GITLAB’a zakłada nieograniczoną ilość użytkowników, którzy mogą współpracować z nieograniczoną liczbą projektów publicznych i prywatnych. Limit występuje w objętości repozytoriów i wynosi on 10 GB.
Płatne plany cenowe platformy GITLAB, GITHUB i Bitbucket
Każdy z płatnych planów hostowanych w chmurze usług oferuje nieograniczoną liczbę pamięci masowej do użytku prywatnego, a także obsługę poczty e-mail. Jak wyglądają poszczególne oferty?
GITHUB w wersji chmurowej zasadniczo oferuje to samo, co w przypadku darmowego planu. Różnica polega na nieograniczonej ilości hostowanych prywatnych repozytoriów. Poza tym zostaje zniesione ograniczenie co do liczby zaangażowanych w projekt użytkowników dysponujących kontem osobistym. Koszt usługi GITHUB zaczyna się od 25 dolarów za miesiąc dla 5 osób, a każdy dodatkowy użytkownik kosztuje dodatkowe 9 dolarów miesięcznie. Samodzielnie hostowany plan GITHUB Enterprise zaczyna się od kwoty rzędu 2500 dolarów rocznie za 10 użytkowników.
Najtańszy plan hostingu w chmurze usługi Bitbucket możemy kupić już za 10 dolarów miesięcznie dla 10 użytkowników. Płacąc 100 dolarów miesięcznie, możemy korzystać z usługi z nielimitowaną liczbą członków zespołu. Za samodzielnie hostowany plan Bitbusket Small Temas i Grow Teams zapłacimy jednorazową opłatę wynoszącą skromne 10 dolarów. Wersja Bitbucket Enterprise odznacza się limitem 2000 użytkowników.
GITLAB oferuje wyłącznie płatny plan do samodzielnego hostingu. Jest to GITLAB Enterprise kosztujący 39 dolarów za użytkownika na rok. Plan nie zakłada limitów w przypadku liczby członków zespołów.
Główne zalety repozytorium kodu
Nad korzyściami wynikającymi ze stosowania systemów utrzymywania kodu możemy rozwodzić się w nieskończoność, zwłaszcza że obecnie trudno wyobrazić sobie jakiekolwiek działania deweloperskie bez ich wykorzystywania.
Repozytorium kodu to podstawowe narzędzie programisty. Umożliwia ono automatyczne wykrywanie zmian w plikach i automatyczne dokonywanie update’ów. Każdy update repozytorium kodu jest opisywany wiadomością, a historia zmian oraz ich autorzy są odpowiednio wyszczególnieni. Dzięki temu możliwe jest łatwe znalezienie potencjalnie występujących problemów oraz przywrócenie kodu do poprzedniego stanu.
Co więcej, repozytoria umożliwiają tworzenie specjalnych wersji kodu opisujących konkretne funkcje, co sprzyja przeprowadzaniu testów. Poza tym dzięki rozbudowanej dokumentacji kodu implementacja tych konkretnych funkcji w projekcie przebiega sprawniej i mniej chaotycznie.
Do niewątpliwych zalet unifikujących współpracę zespołów zaliczamy również wspólną wersję repozytorium we wszystkich środowiskach oraz brak konieczności utrzymywania plików konfiguracyjnych, które są inne dla każdej z maszyn. Warto wspomnieć także o lekkości repozytoriów w kontekście objętości danych. Odpowiednio skonfigurowane repozytorium zajmuje o wiele mniej miejsca niż cały projekt.
Repozytorium zapewnia także ułatwione rozwiązywanie konfliktów i kolizji, a dzięki uniwersalnemu workflow możliwe jest ujednolicenie zasad współpracy, co jest szczególnie istotne w przypadku pracy międzynarodowej. Dodatkowo repozytoria dostarczają interfejsy graficzne ułatwiające wymianę informacji w przypadku wystąpienia sporów (tzw. issues) i wspierają code review.
Słowem podsumowania
Wykorzystywanie repozytorium kodu to dobra – a w zasadzie konieczna – praktyka. Brak stosowania systemu kontroli wersji w projekcie od razu sugeruje, że wraz z realizacją projektu wystąpią problemy, kolizje i spory, które znacząco utrudnią współpracę, a w skrajnych przypadkach mogą ją całkowicie pogrzebać. Zatem jeżeli chcesz uniknąć chaosu w projekcie, koniecznie stosuj repozytoria kodu.
Leave a Comment