W duchu open source: kod Panelu klienta OVH upubliczniony

Zapowiedziane podczas konferencji OVH Summit 2016 uwolnienie kodu źródłowego Panelu klienta OVH stało się faktem. Od tej pory każdy może uczestniczyć w jego rozwoju dzięki naszemu repozytorium GitHub.

Po co upubliczniać kod?

Wraz ze stopniowym przeformułowaniem modelu zarządzania OVH, ruszył proces uwalniania naszego Panelu klienta. Tego samego, który stanowi fundament usług OVH i który umożliwia każdemu klientowi zarządzanie swoimi usługami. To oznacza, że skupia się na nim większość działań zespołu UX. Jako programiści, zajmujący się doświadczeniem użytkownika, uważamy, że otwarcie źródeł kodu niesie ze sobą wiele zalet. Korzyści, które wzmacniają nasze przekonanie o tym, iż oprogramowanie open source stało się nieodzownym standardem w dziedzinie usług IT.

Od samego początku OVH kieruje się zasadą współpracy. Zawsze staramy się uważnie wsłuchiwać w sugestie i potrzeby naszych użytkowników oraz jesteśmy otwarci na krytykę. To dzięki temu urośliśmy w siłę jako grupa. Nadszedł moment rozpoczęcia kolejnego etapu opartego na współpracy. Pracując razem przyczyniamy się w znacznej mierze do polepszenia jakości Panelu klienta. Mieliśmy okazję przekonać się o tym za sprawą uruchomionego latem 2016 roku programu bug bounty, ułatwiającego wykrywanie usterek. A także przy okazji poprawiania błędów ortograficznych w interfejsie.

Otwarcie kodu źródłowego, dzięki udostępnionemu rejestrowi zmian czy poleceń GitHub oznacza większą przejrzystość i kontrolę nad projektem.

Ułatwić współpracę

Pierwszym krokiem, który miał umożliwić i upowszechnić współpracę, było otwarcie źródeł. Panel klienta to projekt o bogatej historii.
Prace nad nad nim były podejmowane już wcześniej, więc część naszych zadań wiązała się z podstawą Panelu.

Lista wytycznych otwarta na sugestie i komentarze

Nie ma współpracy bez uprzedniego ustalenia jej ram. Zredagowanie przejrzystej dokumentacji stało się priorytetem celem zapewnienia jednorodności wszystkich zgłoszeń, zarówno na poziomie kodu, jak i pod kątem metodologii współpracy. Dokumentacja za mało precyzyjna mogłaby okazać się nieprzydatna. Z kolei zbyt przeładowana i restrykcyjna sprawiłaby, że współpraca stałaby się dla wszystkich uciążliwym i żmudnym procesem. Jako że nie zawsze jest łatwo znaleźć złoty środek, nasze założenia ramowe są otwarte na sugestie użytkowników.

Te wytyczne dla społeczności zawierają następujące pliki:
README.md: opis wymaganego formatu zgłoszeń;
CODE_OF_CONDUCT.md: zasady dobrych praktyk obowiązujące współpracowników;
CONTRIBUTING.md : to nasz zbiór, w którym znajduje się wykaz wszystkich reguł obowiązujących uczestników naszych projektów;
ISSUE_TEMPLATE.md: szablon GitHub, umożliwiający wstępne wypełnienie formularza zgłoszenia problemu. Dzięki zastosowaniu ujednoliconego formatu, zgłoszenia są szybciej rozwiązywane;
PULL_REQUEST_TEMPLATE.md : identyczny jak szablon ISSUE_TEMPLATE, ale stosowany w odniesieniu do komend pull requests;
LICENSE.md: opisuje szczegóły standardowej « 3-klauzulowej licencji BSD », na której mają opierać się projekty.

Zestaw narzędzi

Oprócz wytycznych, udostępniamy również rozwiązania pomocne w stosowaniu przyjętych zasad:
Commit-preformatter: narzędzie do formatowania zmienionych plików, pozwala na zachowanie formatu wiadomości zgodnego z tym, jaki opisano w naszych wytycznych i który opiera się na poniższych schemacie:

<emoji> <type>(<scope>): <subject>
<BLANK LINE>
<body>Espace Client Le Blanc
<BLANK LINE>
<footer>

Naszą inspiracją były już istniejące normy, jak choćby Angular, celem zapewnienia współpracującym użytkownikom znanego środowiska:


Generator rejestru zmian : chodzi o skrypt Node.js pozwalający na wygenerowanie rejestru zmian w formacie standardowym. Rejestr zmian powstaje poprzez format wiadomości commit.

[i]Przykład rejestru zmian. Chatbot.[/i]

« Linter » JavaScript oraz « linter » stylesheet : są to narzędzia sprawdzające poprawność składniową i format kodów, tak aby były możliwie najbardziej jednorodne w jak największej liczbie zgłoszeń. Czytanie kodu jest łatwiejsze, jeżeli nie zawiera on zbyt skomplikowanej składni, dzięki czemu prościej skupić się na samym kodzie.

Opisane narzędzia stanowią reguły współpracy, z którymi należy się zapoznać przed przystąpieniem do prac nad Panelem klienta. Dlatego wykorzystujemy uniwersalny standard Makefile, dzięki któremu proces instalacji Panelu klienta jest prostszy. Najważniejsze są w nim dwa polecenia:

make install
make dev

 2

Pierwsze polecenie instaluje zależności niezbędne do poprawnego funkcjonowania Panelu klienta. Drugie uruchamia środowisko deweloperskie. Można działać!

Aktualizacja kodu: etap czasochłonny, lecz nieunikniony

Aby Panel klienta mógł funkcjonować, niezbędne są elementy konstrukcyjne oprogramowania, nazywane komponentami. W celu ich uwolnienia, stworzyliśmy 53 zgłoszenia GitHub, które następnie opublikowaliśmy na NPM i Bowerze. Otwarcie tak dużej ilości komponentów było procesem niezwykle czasochłonnym, tym bardziej, że kod nie zawsze odpowiadał aktualnym standardom jakościowym.

Po oczyszczeniu kodu, opublikowaliśmy najważniejsze elementy konstrukcyjne. Następnie postanowiliśmy udostępnić w repozytorium GitHub Panel klienta Telecom. Dlaczego najpierw Panel klienta Telecom? Jako najbardziej aktualny element, dodany do Panelu klienta, panel administracyjny Telecom zawierał proporcjonalnie najmniej tzw. kodu „legacy”, czyli kodu tzw. „odziedziczonego”. Trzon pracy polegał na weryfikacji, czy żaden komentarz lub fragment kodu nie spowoduje luki w zabezpieczeniach, nie okaże się przestarzały lub nie będzie zawierał wewnętrznych komentarzy. Po upublicznieniu tej części Panelu klienta, nadszedł czas na panel Managera usługi Cloud. Uwzględniając, iż kody paneli administracyjnych Cloud i Telecom mają zbliżoną architekturę, zastosowaliśmy tę samą metodę.

Mroczna przeszłość Panelu klienta Web

Dwa panele klienta wymagały aktualizacji w takim stopniu, że opublikowanie ich bez wprowadzenia zmian okazało się niemożliwe: panel Manager Web oraz panel Manager poświęcony serwerom dedykowanym.

Postanowiliśmy zaktualizować najbardziej wymagające elementy Panelu klienta, zaczynając od tego z najdłuższą historią: panelu Managera Web. Aby lepiej zobrazować skalę prac, można sobie wyobrazić około 32 000 linii JavaScript, 800 szablonów HTML i stosy plików CSS. Nie chodziło zatem odświeżenie wyglądu. Tego typu prac nie przeprowadza się za jednym zamachem. Potrzebna jest sekwencja wielu drobnych i w pełni kontrolowanych zadań

W pierwszym kroku przebudowaliśmy kod. Oznaczało to przegląd wszystkich jego części, a w szczególności reorganizację plików JavaScript i ich migrację do ES6 oraz do AngularJS w wersji nowszej niż 1.3. Pozwoliło nam to dostosować się do aktualnych standardów, popularniejszych w społecznościach pracujących nad projektami GitHub. Aby w pełni zabezpieczyć się przed niebezpieczeństwem regresji, zastosowaliśmy narzędzia, takie jak « prettier » czy « SonarJS ». Są one niezwykle pomocne przy wykrywaniu błędów i w procesie ujednolicania plików.

Następnie, przyszła kolej na usprawnienie i aktualizację plików HTML. Na tym etapie ponownie uprościliśmy DOM i przeprowadziliśmy migrację projektu do tych samych bibliotek, w których znajdują się panele administracyjne Telecom i Cloud, jak na przykład Bootstrap 3. Po zakończeniu tego etapu prac, zastosowaliśmy opisany powyżej proces w celu otwarcia źródeł Panelu klienta usług Cloud i Telecom. Ten sam zakres prac bęzie powtórzony w przypadku Panelu klienta do zarządzania serwerami dedykowanymi, który otworzyliśmy siedem miesięcy temu.

Komponenty używane w panelu Manager Web zostały opublikowane w repozytorium GitHub we wrześniu 2017 roku.

Make the fork be with you

Uwolnienie kodu Panelu klienta OVH to szeroko zakrojony projekt przebudowy. Do tej pory położone zostały zaledwie jego podwaliny. Następne etapy to kolejne ważne momenty dla samej społeczności oraz dla wszystkich planujących udział w projekcie.
Jednym z naszych celów jest umożliwienie każdemu utworzenie własnego forka Panelu klienta OVH i wdrożenia go na swojej infrastrukturze. Czy będzie to dostosowanie Panelu klienta pod konkretne potrzeby czy też utworzenie wersji typu „white label” - Panel klienta należy do użytkownika.
Mówiąc o Panelu klienta OVH, poruszamy kwestie dotyczące kilku baz kodów, z których każda powiązana jest z konkretnym rodzajem produktów OVH: Telecom, Cloud, Web, Serwery dedykowane. Dzięki temu mogliśmy stopniowo dążyć do uwolnienia kodu Panelu klienta.

W najbliższych miesiącach będziemy pracować nad technicznym i ergonomicznym ujednoliceniem Panelu klienta OVH.