Są takie rzeczy, z których programiści, szczególnie w początkowych fazach "kariery", kiedy skupiają się wyłącznie na pisaniu oprogramowania, nie do końca zdają sobie sprawę. Wiążą się one głównie z formalnościami i stwierdzeniem smutnego faktu, że kodowanie niekoniecznie zostalo stworzone dla przyjemności, ale przede wszystkim jest składnikiem przedsięwzięcia biznesowego klienta. A co za tym idzie, niektóre aspekty mogą wydawać się bzdurne z perspektywy młokosa, ale są istotne dla zachowania warunków współpracy oraz radzenia sobie z dalszym rozwojem wypadków (zarówno pozytywnym, jak i negatywnym).
Jednym z takich kroków jest przekazywanie kodu źródłowego zleceniodawcy. Na początku zastrzegę, że w tym tekście nie będziemy zajmować się prawnym aspektem tego procesu - w sieci znajdziecie dużo opracowań prawników na ten temat, poruszających różne niuansy (np. sam obowiązek czy poufność). My tutaj skupimy się na sytuacji, w której software house taki kod musi przekazać i zastanawia się nie czy, ale jak to zrobić.
Na początek powiedzmy (albo raczej napiszmy) sobie, co rozumieć poprzez kod źródłowy oraz po co może być on potrzebny zleceniodawcy. Jeśli chodzi o odpowiedź na pierwsze pytanie, to za kod źródłowy przyjmuje się zazwyczaj wszystkie pliki pozwalające zmodyfikować, zbudować czy też odtworzyć oprogramowanie, które działa na serwerze lub w innym środowisku. Innymi słowy, nie zawsze jest to tylko zawartość repozytorium Gita programistów, choć zazwyczaj do tego się to ogranicza. Jednak bywają sytuacje, w której potrzebne (lub wskazane) jest dostarczenie np. kompletnego folderu z bibliotekami lub zewnętrzne pliki, z których można odtworzyć pewne dane w bazie danych (inna sprawa, że w takim układzie powinny wchodzić one w skład zawartości repozytorium). Kodem źródłowym nie jest np. zbudowana wersja aplikacji angularowej - owszem, można ją umieścić na serwerze, ale nie da się w łatwy sposób zmodyfikować takiego oprogramowania, a zatem będzie ona bezużyteczna dla programistów utrzymujących kod.
Tak naprawdę to, co ma zostać przekazane, jest ustalane indywidualnie pomiędzy klientem a wykonawcą. Tak, jak pisałem - najczęściej jest to czysty kod źródłowy, a więc aktualna zawartość repozytorium, ale niekiedy zleceniodawcy potrzebne są dodatkowe materiały. Zwracam uwagę na słowo "aktualna" - repozytorium zawiera zwykle wiele gałęzi i nie zawsze to ta główna ("master" lub "main") jest wersją umieszczoną na serwerze. Należy zatem zadbać o to (choćby z uwagi na profesjonalizm wykonawcy), aby dostarczyć klientowi faktyczną wersję oprogramowania. Oczywiście, pomijamy tutaj ew. dokumentację czy instrukcje.
Natomiast powstaje pytanie, dlaczego klient może chcieć mieć dostęp do kodu źródłowego. Branża IT jest pod tym kątem specyficzna - przecież elektronik, mający zbudować urządzenie dla klienta, nie przekaże mu osobno wszystkich przewodów, oporników i kondensatorów, a budowlaniec - cegieł oraz zaprawy. Z kolei oprogramowanie jest dość plastyczne i najczęściej modyfikowane lub rozbudowywane w przyszłości. W dodatku dość łatwo i tanio (wręcz darmowo) można uzyskać tutaj materiał, z którego powstaje końcowy produkt. A zatem, ponownie pomijając kwestie prawne, licencje i zapisy w umowach, zleceniodawca może poprosić o dostęp choćby w celu zabezpieczenia się przed utratą wykonawcy. Bywają sytuacje, w których należy przenieść realizację do innego wykonawcy i bez kodu źródłowego jest to zazwyczaj niemożliwe. Istnieją też sytuacje, w których to sam zleceniodawca po jakimś czasie uruchamia swój zespół utrzymujący dalej oprogramowanie i musi na czymś pracować lub czasowo współdzialać z oryginalnym wykonawcą.
Przekazywanie kodu źródłowego ma miejsce najczęściej w jednym z trzech momentów:
- po każdym etapie/sprincie - strony mogą umówić się na przesyłanie materiałów po każdej zakończonej fazie projektu, co najczęściej jest połączone z podpisaniem protokołu odbioru. Jest to całkiem dobre rozwiązanie, choć warto dodać je do zadań sprintowych, gdyż w ferworze walki z kodem programiści czasem zwyczajnie o tym nie pamiętają.
- po ukończonym projekcie - w teorii wydaje się najbardziej rozsądnym rozwiązaniem, jednak warto pamiętać, że rzadko bywa sytuacja, w której oprogramowanie jest faktycznie skończone. Brzmi to niedorzecznie, ale w dobie wersji MVP, metodyk zwinnych czy fazy utrzymania fakt sfinalizowania projektu nie musi być taki oczywisty. Zawsze jest coś do zrobienia, rozwinięcia i w naprawdę niewielu przypadkach można powiedzieć to jest już koniec, nie ma już nic, jesteśmy wolni, możemy iść.
- po zakończeniu współpracy - nie da się ukryć, że bywa tak, iż strony się rozstają, gdy wszystkie zobowiązania biznesowe zostały zrealizowane. To oczywiście moment, w którym zleceniodawca także może się ubiegać o dostarczenie kodu źródłowego od wykonawcy, jeśli nie ma innych przeszkód (np. licencyjnych).
Wiemy już "co", "dlaczego" i "kiedy". Natomiast przejdźmy teraz do pytania "w jaki sposób" - jakie są metody na przekazanie kodu źródłowego?. Rozwiązań jest co najmniej kilka.
- przekazanie zabezpieczonego archiwum ZIP - albo i niezabezpieczonego, jeśli zleceniodawca lubi zastrzyk adrenaliny. Jest to chyba najczęściej spotykane, gdyż najbardziej oczywiste - przecież to jest jakaś paczka plików, którą można wysłać. Należy jednak pamiętać o tym, aby zrobić to odpowiednią drogą. Najlepiej, oczywiście, osobiście, poprzez pendrive'a lub niegdyś płytę CD. Natomiast najczęściej takie archiwa przekazuje się w sposób elektroniczny, zabezpieczając je hasłem, które następnie wysyłane jest już bezpieczną metodą (choćby przez SMS).
- przesłanie na wyznaczony serwer (S)FTP klienta - jest to odmiana poprzedniej wersji, w której archiwum jest przekazywane w sposób elektroniczny, ale najczęściej wiąże się z zaszyfrowaniem danych (np. poprzez GPG). Natomiast jest to droga rzadko stosowana, gdyż wymaga odpowiedniej technologii po stronie klienta. Dużo częściej stosuje się albo "zwykłe" przekazanie, albo...
- umieszczenie kodu na zewnętrznym repozytorium - skoro wykonawca i tak wykorzystuje repozytorium do utrzymania swojego kodu, to zwykle dużo prostsze jest utworzenie repozytorium Git przez klienta (lub drugiego przez wykonawcę), po czym przekazanie oznacza standardowy "push" na innego "remote'a". Ma to zaletę nie tylko w postaci prostoty, ale też dodatkowego backupu. Istnieje jednak też wada - nie zawsze wykonawca zgadza się na pokazywanie całej historii tworzonego kodu (np. nie chcąc ujawniać personaliów programistów), a to bardzo trudne (łamane na "niemożliwe") do uniknięcia w tym przypadku. Bardzo rzadko praktykowane jest też udostępnienie klientowi bezpośrednio repozytorium wykonawcy - jest to niebezpieczne na kilku płaszczyznach (personalia, zabezpieczenia, nieuprawnione ingerowanie w harmonogram) oraz naruszenie pewnej "enklawy" programistów.
Niezależnie od ścieżki, warto wspomnieć o tym, że przekazanie kodu źródłowego nie oznacza, że wykonawca traci do niego dostęp. Zawsze jest on potrzebny choćby ze względu na dalsze modyfikacje, umowę serwisową czy też obsłużenie gwarancji. Natomiast istotne i dla higieny współpracy, i dla profesjonalizmu wykonawcy jest udostępnienie kodu źródłowego klientowi, jeśli - oczywiście - ten sobie tego życzy i nie jest to ograniczone prawnie.
Pozdrawiam i dziękuję - Jakub Rojek.