Zostań programistą Open Source w społeczności Drupala

Drupal jako jedna z najpopularniejszych platform CMS może poszczycić się ogromną społecznością, która każdego dnia pracuje zarówno nad rozwojem i usprawnianiem rdzenia systemu, jak i projektów rozszerzających jego funkcjonalności. Społeczności tej przyświeca motto: “współpraca zamiast rywalizacji” - zamiast oferować wiele konkurujących ze sobą modułów, powstają pojedyncze rozwiązujące wybrany problem.

Modularny system pozwala nawet mniej doświadczonym programistom Drupala pomagać w codziennych pracach programistycznych nad różnego typu projektami. Jak w takim razie włożyć odrobinę własnego wkładu w środowisko Drupala?

Zanim stworzę własny projekt

1. Research!

Zanim założysz jakikolwiek projekt, najpierw poszukaj dobrze, czy taki projekt już nie powstał. Może okazać się, że np. moduł, który chciałbyś stworzyć już istnieje lub wystarczyłoby zgłosić propozycję rozszerzenia jego funkcjonalności. Warto również przejrzeć listę propozycji modułów i wspomóc kogoś w pracach nad jego rozwojem.

2. Twój profil na portalu drupal.org

Jeżeli jeszcze nie posiadasz własnego konta na portalu drupal.org, to zdecydowanie zachęcamy do jego założenia. Dzięki niemu będziesz w stanie zarówno tworzyć nowe projekty, jak i zgłaszać problemy, i łatki (patche) do istniejących projektów.

3. Projekt typu sandbox czy pełnoprawny projekt?

Portal drupal.org pozwala na stworzenie dwóch typów projektów. Pierwszy z nich to projekt typu sandbox (piaskownica). Jest to w zasadzie poligon doświadczalny dla nowo opracowywanego modułu. Zazwyczaj jego twórcy nie biorą żadnej odpowiedzialności za istniejący tam kod, dopóki nie ukończą prac nad wersją spełniającą przynajmniej podstawowe wymagania co do funkcjonalności i stabilności. Na tym etapie najczęściej dochodzi do wypromowania projektu sandbox do pełnoprawnego projektu, w którym możliwe jest tworzenie wersji, wydań, zgłoszeń, itp.

Tworzenie projektu

Proces tworzenia projektu nie jest szczególnie skomplikowany. Na początek wystarczy tylko kilka podstawowych informacji - nie musimy posiadać nawet żadnego istniejącego kodu.

Dodanie własnego projektu możemy dokonać z poziomu swojego profilu, przechodząc na zakładkę projektów (Your projects) lub bezpośrednio ze strony Add a new project.

Wybieramy rodzaj projektu. W naszym przykładzie będzie to moduł.
Uzupełniamy pole z nazwą modułu, nazwą maszynową (short name), a także typ projektu (sandbox/full).
Dodatkowo warto podać organizację, która wspiera rozwój projektu (jest to dodatkowa forma promocji dla firmy) oraz dodatkowe osoby, które będą współpracowały przy utrzymaniu projektu.

Praca z kodem

1. Git

Na początek potrzebujemy uzyskać dostęp do repozytoriów opartych o system kontroli wersji Git. Portal Drupal.org korzysta z platformy GitLab, która częściowo jest zintegrowana z samym portalem. W edycji profilu należy dodać swój klucz SSH.

W systemach Linuxowych najczęstszą komendą na pobranie zawartości swojego klucza publicznego SSH jest:

​​​​​​​cat ~/.ssh/id_rsa.pub

Następnie w sekcji Git access za pierwszym razem musimy wyrazić kilka niezbędnych zgód, a także skonfigurować nazwę użytkownika i adres e-mail, jeśli nie są to domyślne dane z profilu.

Po uzyskaniu dostępu do systemu kontroli wersji, pracując na wybranych repozytoriach nasze zmiany mogą być zatwierdzane zarówno z wykorzystaniem publicznego adresu e-mail, jak i ze zanonimizowanym adresem dostarczanym przez portal drupal.org, np. [email protected].

2. Branch deweloperski

Wszystkie projekty contribowe, jak i rdzeń Drupala, trzymają się stałej konwencji numerowania wersji. 
Dla rdzenia jest to np. (8.8.5) według schematu:

[MAJOR VERSION].[MINOR VERSION].[PATCH]

Dla projektów contribowych, np. (8.x-2.x) według schematu:

[MAJOR CORE VERSION].x-[MODULE VERSION].x

Jeżeli pracujemy obecnie nad wersją modułu 1.15, to główny branch wersji, a zarazem branch deweloperski, to branch: 8.x-1.x
Branche deweloperskie nie wymagają dodatkowego suffixu ‘-dev’ ani dodania tagu. Aby jednak branch deweloperski widoczny był na stronie projektu, należy utworzyć nowe wydanie.

3. Tworzenie pre-relasów i releasów

Kiedy czujemy, że projekt nad którym pracujemy zaczyna nabierać kształtów i coraz więcej funkcjonalności realizuje nasze założenia, warto stworzyć pre-release, czyli tak naprawdę wydanie niestabilne.
Zgodnie z przyjętą konwencją takie wydania należy opatrzyć przyrostkiem -[type][number]. Do dyspozycji mam typy:

• alpha,
• beta,
• rc (release candidate),

które w dużym uproszczeniu definiują jak bardzo blisko naszemu projektowi do stabilności. Więcej informacji na ten temat można odnaleźć w artykule Release naming conventions.
Jeżeli jednak jesteśmy przekonani, że nasz moduł jest w pełni stabilny i dobrze przetestowany, możemy stworzyć stabilne wydanie (bez żadnego sufixu), np. 8.x-2.5.
Bez względu na to jaką drogę obierzemy, należy najpierw dodać git tag, na bazie którego zostanie utworzone nasze wydanie. Wykonujemy to za pomocą komendy:

git tag 8.x-1.1-alpha1

Następnie musimy wysłać nasze zmiany do repozytorium:

git push origin 8.x-1.1-alpha1 - pojedynczy tag
git push origin --tags - wszystkie tagi

Tak wysłany tag możemy teraz wykorzystać do utworzenia nowego wydania (w edycji projektu - Releases / Add new release).

Należy pamiętać, że każdy tag może zostać wykorzystany tylko raz, a użyte tagi nie mogą już nigdy zostać usunięte z repozytorium (nałożona jest blokada).

Utrzymanie projektu

1. Kolejka zgłoszeń

To miejsce gdzie tak naprawdę żyje projekt. Zgłaszane są tu wszelkie błędy, propozycje usprawnień, nowych funkcjonalności, itp. (przykładowa kolejka zgłoszeń (issue queue) dla projektu Droopler). Każdy zalogowany użytkownik portalu może zarówno dodawać nowe zgłoszenia (issue), komentować, jak i zgłaszać patche.
Każde zgłoszenie opatrzone jest statusem, którego domyślna wartość to "Active". Pełną listę statusów można sprawdzić w artykule Status settings of issues.

2. Zgłaszanie i akceptacja patchy

Patche mogą zostać dołączone do issue jako załącznik w komentarzu lub wraz z nowo zakładanym issue. Lista zgłoszonych patchów znajduje się w podsumowaniu pod pierwszym postem w danym issue.
Jeżeli do naszego projektu został zgłoszony patch, to jako autorzy powinniśmy go zweryfikować i zmienić odpowiednio status issue. Jeśli zaproponowany patch działa poprawnie, należy go zacommitować, honorując przy tym autora patcha poprzez dodanie parametru --author np.
 

git commit 
-m 'Issue #[issue number] by [user name]: [issue title]' 
--author="Sayco <[email protected]>"

W przypadku gdy sami znajdziemy błąd w funkcjonalności jednego z projektów, czy też samego rdzenia Drupala, możemy również zgłosić nasz własny patch. Aby zacząć pracę nad taką poprawką, musimy wykonać kilka kroków:

Klonujemy repozytorium projektu (strona projektu - Browse code repository).

git clone [email protected]:project/paragraph_view_mode.git

Przechodzimy do gałęzi której dotyczy błąd, np.​​​​​​​:

git checkout 8.x-1.x

Po dokonaniu niezbędnych zmian mamy różne możliwości wygenerowania patcha. Jeżeli zmian nie było zbyt wiele i nie potrzebowaliśmy ich zacommitowywać, wystarczy wygenerować patch na podstawie powstałych różnic:

git diff > [project]-[description]-[issue-number]-[comment-number].patch

Jeżeli natomiast zmian było więcej, w zależności od tego, co chcemy osiągnać, możemy wygenerować patch podając: zakres commitów, poszczególne commit hashe, liczbę commitów do danego commit hasha, np.

git format-patch -<n> <SHA1> 
--std-out > [project]-[description]-[issue-number]-[comment-number].patch

Jak zauważyliście w przykładach powyżej nazwa patcha ma określoną konwencję nazewnictwa. Najczęsciej opatrujemy taki plik nazwą projektu, krótkim opisem, numerem issue, a także numerem komentarza, w którym zgłaszany będzie patch.
Niekiedy, poza samym patchem, konieczne jest dołączenie interdiff'a, czyli pliku różnicowego między naszym patchem, a np. poprzednio zgłoszonym patchem, na bazie którego dokonywaliśmy określonych zmian. Więcej na ten temat można znaleźć w artykule "Creating an interdiff"

3. Security Advisory Policy

Na pewnym etapie rozwoju projektu możemy stwierdzić, że jest on wystarczająco stabilny i bezpieczny, aby ubiegać się o SAP (Security Advisory Policy). Jest to system otwartego i jawnego informowania o incydentach w Drupal core oraz projektach contribowych. Wykryte incydenty trzymane są w tajemnicy (o ile jest to możliwe) do momentu stworzenia wydania z odpowiednią łatką bezpieczeństwa przy wsparciu Drupal Security Team.

Projekty objęte SAP otrzymują na stronie projektu ikonę tarczy oraz zielone tło dla wszystkich wydań stabilnych.
​​​​​​​Jest to wyraźne wyróżnienie na stronie, jednocześnie podnoszące wartość projektu w oczach potencjalnych użytkowników.

3.1 Jak się ubiegać?

• Zakładamy nowy issue na stronie https://www.drupal.org/project/issues/projectapplications.
• Definiujemy tytuł wg schematu [WERSJA CORE] [nazwa modułu], np. [D8] Autotile.
• Ustawiamy status issue na "Needs review".

3.2 Co musi spełnić nasz projekt?

• Musi spełniać założone funkcjonalności znajdujące się w opisie projektu.
• Musi pomyślnie przejść PAReview - narzędzie do weryfikacji projektów drupalowych online.
• Musi zostać pozytywnie zaopiniowany przez społeczność (głównie weryfikacja jakości i bezpieczeństwa kodu).

Proces weryfikacji jest jednorazowy dla danego użytkownika portalu. Po pozytywnym rozpatrzeniu użytkownik ma możliwość utworzenia dowolnej liczby projektów objętych SAP, bez konieczności przechodzenia procesu weryfikacji.

Podsumowanie

Jak zdołaliście zauważyć istnieje kilka sposobów na udzielanie się w społeczności Drupala. Możemy zarówno wspierać istniejące, jak i też rozwijać własne projekty, przyczyniając się przy tym do rozwoju otwartego oprogramowania. Raz dobrze wykonany moduł może posłużyć nam i wielu innym użytkownikom jeszcze wiele razy w wielu projektach.
Myślę, że dla nas, jako programistów, jest to pewien rodzaj misji, czy też forma odpłacenia społeczności za możliwość korzystania z darmowego oprogramowania na własny użytek. Oczywiście jest to także wspaniały sposób na wymianę wiedzy, doświadczenia oraz autopromocję. Warto wspomnieć, że możemy przy tym promować nie tylko siebie, ale także organizację/firmę, dla której pracujemy, a nawet klientów, na rzecz których wykonujemy dane funkcjonalności. Ja już rozwijam projekty na portalu Drupal.org. Ty też możesz to robić. Zacznij już dziś!