Jak w Droptica działa zespół Drupal Support?

W poprzednim poście opisałem, dlaczego zdecydowaliśmy się stworzyć osobny zespół wsparcia dla stron na Drupalu. Tym razem opiszę, jak działa u nas taki zespół. 

Zadania zespołu Drupal Support

Zespól wsparcia ma trzy główne cele

1. Pilnuje, żeby wszystkie strony działały poprawnie

Wielu naszych klientów polega na sprawnie działającej stronie internetowej. Często aplikacje, które utrzymujemy, są źródłem ich zarobków. Przerwy w dostawie usługi oznaczają dla nich skargi, utratę przychodów itp.

Nasz zespół wsparcia skupia się na tym, by te strony działały bez zarzutu i szybko reaguje, jeśli pojawią się jakieś przeszkody.

2. Dba o bezpieczeństwo

Aktualizacje bezpieczeństwa dla rdzenia i modułów Drupala są wydawane regularnie. To samo z technologiami składającymi się na stack Drupala - oprogramowanie serwerów, wersje PHP itp. Nasz zespół wsparcia gwarantuje, że wszystkie strony są aktualne i nie wykazują podatności na znane sposoby ataku. 

Kiedy wypuszczane są aktualizacje bezpieczeństwa, musimy zaktualizować ponad 100 stron, tak szybko, jak to możliwe. Aby się z tym uporać, mamy usystematyzowany proces działań, którymi zajmuje się właśnie zespół supportujący.

3. Wykonuje drobne usługi programistyczne

Wiele stron po zakończonym procesie rozwoju nie potrzebuje już etatowego zespołu programistycznego. Niemal każda strona jednak potrzebuje od czasu do czasu trochę pracy. Czasem jest to nowy landing, integracja z serwisem zewnętrznym, poprawa błędów albo rozwiązanie jakiegoś drobnego problemu. 

Jeśli nie są to skomplikowane zadania, zespół wsparcia pomaga również i z tym. Jeśli nowe funkcje wymagają więcej pracy, zadania są rozkładane w czasie i przekazywane jednemu z zespołów deweloperskich. 

Proces wsparcia

W Droptica wprowadzamy automatyzację, gdzie to możliwe. Wszystkie strony podlegają temu samemu procesowi, aby nie tracić czasu i zapewnić przewidywalne rezultaty. 

Zautomatyzowane środowisko testowe

Każda strona, której wsparcia się podejmujemy przechodzi przez proces onboardingu, który pozwala nam na dalsze łatwe utrzymanie. Podczas tego procesu tworzymy następujące elementy:

1. Replikowalne środowisko developerskie na Dockerze, które możliwie wiernie odwzorowuje środowisko produkcyjne.
2. Zautomatyzowane środowisko testowe dostępne dla klienta (strona testowa). Tu wystawiamy pracę do wglądu przed wypuszczeniem zmian na wersję produkcyjną. Klient może go także używać do własnych testów czy treningu. Jeśli zajdzie taka potrzeba, możemy stworzyć wiele klonów tej strony.  
3. Zautomatyzowany proces kopiowania strony produkcyjnej na środowiska testowe i developerskie. Ten proces pozwala nam, za jednym kliknięciem, skopiować najnowszą wersję środowiska produkcyjnego do innych środowisk i wdrożyć tam nowy kod. 
4. Zautomatyzowany proces wdrożeń, który pozwala na publikowanie zmian na produkcji szybko i w z góry przewidziany sposób.

Dzięki automatyzacji możemy szybko (w przeciągu minut) skopiować stronę produkcyjną na środowisko programistyczne, sprawdzić występowanie błędów, naprawić je, wypchnąć do testu i zaprezentować rozwiązanie klientowi. Jeśli zmiany zostaną zaakceptowane, równie szybko będą wysłane na stronę produkcyjną. 

Proces przepływu pracy w supporcie

Zachęcamy naszych klientów do korzystania z Jira, ale niektórzy wolą komunikację poprzez e-mail albo Skype. Niezależnie od wybranej metody, każde zapytanie logujemy w Jira. Tu zaczyna się cykl życia zadania. W zależności od powagi, pilności, typu i wersji wsparcia, z której klient korzysta, zadanie zostaje ustawione w kolejce i oczekuje, żeby programista się go podjął.

Po wielu próbach w Jira następujące statusy opisują stan, w którym aktualnie znajduje się zadanie:

1. To do - to zadanie jest nowe. Nikt nad nim jeszcze nie pracował.
2. Needs work - rozpoczęto pracę nad zadaniem, ale nie zostało skończone i nie jest aktywnie opracowywane w danej chwili. To może być zadanie, które nie przeszło testów naszego zespołu Quality Assurance i zostało zwrócone do poprawy lub developer, który nad nim pracował, musiał zająć się czymś pilniejszym.
3. In progress - programista aktywnie pracuje nad zadaniem. Wykonywane jest na osobnej gałęzi (ang: branch) kodu w GIT, która zostanie złączona z głównym branchem, tylko jeśli przejdzie przez QA. Dzięki temu na produkcję wdrożone są tylko przetestowane, działające rozwiązania. 
4. Feedback/Impediment - zadanie wymaga więcej informacji od klienta lub kogoś innego (np. zewnętrznego dostawcy) i oczekujemy na więcej danych. 
5. Code review - developer kończąc pracę wykonuje pull request z kodem. Zadanie oczekuje w tej chwili na przegląd jakości kodu. Bardziej doświadczony developer sprawdzi, czy kod jest poprawny, ma sens i czy spełnia standardy Drupala.
6. QA - zadanie przeszło code review i jest obecnie testowane przez zespół jakości (Quality Assurance). Typy testów mogą być różne, od prostego ręcznego sprawdzenia do szeroko zakrojonych zautomatyzowanych testów regresji pożądanych funkcji i wyglądu. Zazwyczaj zespół QA buduje automatycznie wersję testową strony na branchu developerskim i wykonuje niezbędne testy. Jeśli kod przejdzie test, klient jest informowany o tym, że jeśli chce, może sprawdzić zastosowane rozwiązanie. 
7. PO review - (Sprawdzenie przez Product Ownera) - uważamy, że praca jest skończona i rozwiązanie jest przedstawione klientowi na stronie testowej. 
8. Ready to deploy - Product owner zatwierdził rozwiązanie i jest ono gotowe do wdrożenia na produkcję.
9. Done - zadanie zostało ukończone, a kod wdrożony na wersję produkcyjną strony. 

Powyższy schemat dobrze opisuje, co dzieje się z każdym zadaniem. Dzięki automatyzacji z łatwością pracujemy nad różnymi zadaniami równolegle, testując i wdrażając rozwiązania w sposób bezpieczny i zaplanowany. 

Strony naszych klientów są pod dobrą opieką.