PowerShell po polsku

Korzystając z PowerShella na co dzień na ogół nie musimy przejmować się tym, jak wygląda tworzony przez nas kod. Nawet proste skrypty na upartego możemy wykorzystywać nie myśląc nawet o systemie kontroli wersji. Jeśli jednak zamierzamy tworzyć moduł, to niestety (a może stety?), bez tego rodzaju narzędzi nie ma raczej sensu kontynuować. Jest to jeszcze istotniejsze wtedy, gdy zamierzamy współtworzyć moduł: możliwość zadbania o to, by poprawiając nasz kod nie cofnąć poprawek koleżanki/kolegi, staje się jeszcze ważniejsze.

Ale nawet jeśli nad modułem pracujemy samodzielnie, to często będzie nam potrzebna możliwość „zapisania” naszego kodu po to, by jednocześnie dokonać zmian najpilniejszych. Zwykle bowiem nowe możliwości mają niższy priorytet, niż naprawianie poważnych usterek w naszym kodzie, które mogłyby doprowadzić do błędnego jego działania. Ponieważ większość projektów związanych z PowerShellem zarządzanych jest przy pomocy gita, to tego narzędzia właśnie użyjemy i w naszym projekcie.

Gałęzie

W poprzednim artykule stworzyliśmy już repozytorium, w tym spróbujemy wykorzystać jego możliwości do tego, by wprowadzać zmiany w sposób kontrolowany. Pierwszym krokiem, zaraz po utworzeniu repozytorium, powinno być zwykle utworzenie gałęzi, na której będziemy dokonywać zmian. Gałąź domyślna (master) na ogół traktowana jest jako miejsce przechowywania kodu gotowego, nadającego się do uruchamiania na produkcyjnych serwerach. Na początku skorzystaliśmy z tej gałęzi tworząc szkielet naszego modułu. Jeśli jednak zamierzamy pisać funkcje, to warto przenieść dalsza pracę do odrębnej gałęzi.

Gałąź możemy utworzyć na kilka sposobów. Osobiście preferuję wykorzystanie do tego celu polecenia git checkout:

Zaleta tego rozwiązania to przeniesienie się na nowoutworzoną gałąź, więc od razu możemy zacząć tworzyć nasz kod.

Odnośnie nazwy gałęzi: istnieje wiele szkół, na ogół połączonych z całym procesem, jakiego należałoby używać w trakcie z korzystania z nich (jak GitFlow). Osobiście nigdy nie zdecydowałem się na ścisłe stosowanie do którejkolwiek z nich. Zwykle po prostu umieszczam moje imię z opisem danej gałęzi. Może być to hasłowy opis (jak ‚pierwszaFunkcja’ widoczny powyżej). Na ogół umieszczam jednak ID w ramach systemu takiego jak JIRA.

Zatwierdzanie kodu

Tworzymy nowe pliki, dopisujemy treść do plików już istniejących czy usuwamy pliki, które nie będą nam dłużej potrzebne. W końcu: zatwierdzamy zmiany przy pomocy git commit. I tu może pojawić się pierwszy zgrzyt (zwłaszcza jeśli korzystamy ze starszej wersji gita i nie podaliśmy opisu zmian):

Mamy więc dwie możliwości: opanować podstawy vima, skonfigurowanie innego edytora bądź zadbanie o opis zmian w linii poleceń.

W przypadku przeprowadzanej operacji zatwierdzania zmian to pierwsze nie jest skomplikowane: wystarczy wiedzieć, jak przejść do trybu edycji (klawisz ‚i’, jak insert, bądź ‚a’ – append) i jak zapisać plik (ESC by wyjść z trybu edycji, :wq), bądź po prostu wyjść z edytora (:q!).

Nie da się ukryć, że użycie linii poleceń będzie jednak prostsze: pamiętać musimy jedynie o podaniu parametru -m i odpowiedniego ciągu znaków.

Ostatnia opcja oferowana jest nam obecnie w trakcie instalacji gita, ale sami też możemy ją ustawić przy pomocy polecenia git config:

Oczywiście, nie musimy wybierać notepad++ – jeśli wolimy inny edytor, to musimy po prostu zmodyfikować parametry polecenia git config. Dla przykładu, jeśli zechcemy skorzystać z Visual Studio Code i zainstalowaliśmy tę aplikację z opcją „dodaj do ścieżki”, to konfiguracja wymaga nieco prostszej składni:

Kod zatwierdzony, pora przesłać go na serwer.

Podaj dalej

Zatwierdziliśmy zmiany w kodzie, ale póki co pozostają one jedynie na naszym komputerze. Oznacza to, że jeśli padnie nam dysk, ktoś „pożyczy” naszego laptopa czy zwyczajnie w trakcie czyszczenia dysku usuniemy troszkę za dużo wynik naszej pracy przepadnie bezpowrotnie.

Jak się tego ustrzec? Oczywiście, przesłać nasze zmiany na serwer! Posłuży nam do tego polecenie git push. Zanim jednak prześlemy dane na serwer warto zadbać o pewien element konfiguracji. Wygodniej bowiem przesyłając zadbać o to, by gałąź zdalna była przez naszego gita „śledzona”. W ten sposób będziemy mieli informację o tym, jak bardzo nasza lokalna gałąź różni się od zdalnej.

Zwykle korzystam w tym celu z ustawienia opcji push.default to current, oraz z polecenia git push -u. Alternatywnie możemy podać docelową gałąź na zdanym serwerze korzystając z parametru –set-upstream polecenia git push:

Efekt finalny będzie taki, że jeśli pojawią się nowe zmiany w naszej lokalnej kopii, to będziemy mogli zauważyć tę różnicę:

Ostatni krok to moment, gdy skończyliśmy pracę nad kodem i chcemy go dołączyć do produkcyjnej wersji naszego modułu. Temu posłuży tak zwany „pull request”.

Łączymy gałązki

Po wytężonej pracy przychodzi wreszcie czas na zebranie owoców. Nasz kod został napisany, pierwsza funkcja jest już w zasadzie gotowa, chcielibyśmy dodać ją do tworzonego przez nas modułu. Co w tej sytuacji powinniśmy uczynić?

Na upartego gałęzie łączyć możemy lokalnie, bez żadnej kontroli, a następnie przesyłać zmiany z naszego komputera na gałąź master. Wadą tego rozwiązania jest to, że tracimy możliwość sprawdzenia, co tak naprawdę uległo zmianie.

O wiele lepszym rozwiązaniem jest skorzystanie z funkcjonalności, którą oferują wszystkie narzędzia „opakowujące” gita w wygodne GUI: pull request (wybaczcie, nie podejmę próby tłumoczenia tego na naszą piękną mowę ). Jest to funkcjonalność, dzięki której możemy poprosić o zmiany w produkcyjnym kodzie oferując przygotowane przez nas uprzednio zmiany. Zwykle (w większych organizacjach) taka zmiana wymaga kontroli innego członka zespołu. Bywa, że dodatkowo przeprowadzane będą automatycznie testy, by sprawdzić, czy kod działa poprawnie (do testów wrócimy w jednym z przyszłych artykułów). Zmiana będzie mieć swój tytuł, opis, sprawdzających, zmiany w kodzie. Zwykle do zmian dodawać można komentarze, nierzadko skutkujące dodatkowymi zmianami. Jakie są z tego korzyści? Przytoczę tylko kilka:

• większa kontrola nad produkcyjnym kodem
• jeśli kod opisuje nasze systemy, zyskujemy swoiste narzędzie do kontroli zmian w środowisku produkcyjnym
• uczymy się od siebie nawzajem rozmaitych technik pisania kodu w PowerShellu i możemy przedyskutować wszystko to, co powoduje różnicę zdań
• poznajemy lepiej dodawany do środowiska produkcyjnego kodu – na koniec co najmniej dwie osoby powinny zaznajomić się z dodawanym kodem, spada „bus factor”

Oto jak taki Pull Request wygląda na platformie GitHub:

Oczywiście, zależnie od wybranej przez nas platformy wyglądać będzie inny. Ważne, że tego rodzaju akcje są zapisywane. Za kilka miesięcy możemy więc sprawdzić, kiedy jakieś zmiany zostały wprowadzone do naszego kodu. Bezcenna wiedza, kiedy chcemy na przykład usunąć skutki poważnej usterki w naszym kodzie.

~ - autor: Bartek Bielawski w dniu 13 czerwca, 2020.

Napisane w PowerShell
Tagi: PowerShell i git, tworzenie modułu w PowerShellu, tworzymy moduł, zarządzanie kodem PowerShelll w git