Developerze, dlaczego ostatnią rzeczą, jaką zrobisz powinien być commit do repo? Po tym zadzieje się automatyczna magia.

Autorzy: Tomasz Soroka

11.04.2017
Z dewelopowaniem, czyli tworzeniem aplikacji, jest trochę jak z pilotowaniem samolotu. Co robi dobry pilot podczas lotu? Nie przeszkadza automatycznemu pilotowi ;)

Nie mam zamiaru dokładać kolejnego głosu do niekończącej się dyskusji o plusach i minusach automatyzacji pracy w IT. Na podstawie swojego doświadczenie mogę jednak śmiało stwierdzić, że powtarzalne zadania po prostu lepiej jest automatyzować. Wychodzę z założenia, że nie warto obarczać prostymi czynnościami programistów. Potencjał ludzkiej inteligencji lepiej wykorzystać w tworzeniu architektury i rozwiązywaniu problemów. Póki co, w tym obszadrze machine learning jeszcze nie osiąga odpowiednich rezultatów. Lean management w LEAWARE to właśnie nacisk na rozwiązywanie problemów i dostarczanie skutecznych rozwiązań przy minimalizowaniu kosztów i sprawnym rozpoznaniu błędów.

Dlaczego ostatnią czynnością wykonywaną przez developera jest wprowadzenie zmiany w repozytorium kodu? To ostatni moment, w którym programista bezpośrednio ingeruje w proces. Później wszystko dzieje się automatycznie...

Poniżej opis, z którego dowiesz się, jak wygląda proces budowania cross-platformowej aplikacji mobilnej (iOS, Android, Windows 10).

  1. Jakość kodu Sprawdzamy kod pod kątem występowania typowych pomyłek, np. użycia złego nazewnictwa klas czy zmiennych. Chodzi o wyłapanie możliwie wszystkich błędów "gramatycznych" w języku programowania - w naszym wypadku jest to zazwyczaj język c#. 
  2. Kompilacje trzy W kolejnym etapie kompilujemy kod. Po każdej zmianie wprowadzonej przez programistów chcemy mieć pewność, że całość poprawnie się skompiluje. Co ważne, każdorazowo na wszystkie 3 platformy. 
  3. Testowanie programu Kolejnym krokiem po prawidłowej kompilacji jest wykonanie kompletu unit testów, które zostały napisane dla aplikacji. To oznacza sprawdzenie, jak gotowa aplikacja zachowuje się w poszczególnych częściach całości. Testów jednostkowych może być nawet kilkaset.  Dzięki nim szybko wiemy, czy dokonane zmiany w kodzie i nowe funkcje nie popsuły niczego w napisanej całości. 
  4. Release Jeżeli testy kodu przebiegają pomyślnie, aplikacja jest gotowa do publikacji. Udostępniamy na naszym wewnętrznym serwerze dystrybucji skompilowane wersje aplikacji dla każdej platformy. W ten sposób wszyscy użytkownicy (klienci) mogą bez problemu pobrać i przetestować aplikację na swoim urządzeniu. Pamiętajmy, że na tym etapie mamy 3 wersje aplikacji na 3 platformy systemowe. 
  5. Testowanie przyjazności Następny etap to testy User Interface. To tu dzieje się magia. Automatyczne testy polegają na pobraniu apki (skompilowanej na odpowiednią platformę) i instalacji na prawdziwych urządzeniach: smarfonach, tabletach, komputerach. Co ważne, sprzęt działa w naszej serwerowni. Wykonywane testy symulują zachowanie użytkownika, dzięki temu nie musimy testować aplikacji ręcznie. Mamy gwarancję, że wszystkie napisane testy wykonują się prawidłowo, czyli że żaden element aplikacji nie przestał nagle funkcjonować. Jeśli pojawia się negatywny wynik, natychmiast otrzymujemy informację zwrotną. Możemy od razu poprawić kod, precyzyjnie w odpowiednim fragmencie.
    Przykładowa konfiguracja planów na serwerze Continous Integration
Muszę dodać, że liczba etapów developowania może się różnić w zależności od konkretnego projektu. Inaczej wygląda proces w przypadku budowanej od podstaw aplikacji, a inaczej kiedy tworzymy aktualizację do nowszej, stabilnej wersji. Przygotowanie wydania finalnego - produkcyjnej wersji aplikacji, która będzie udostępniona w sklepach -  to dodanie jeszcze kilku kroków.  W kolejnych artykułach planuję dokładniej wyjaśnić, jak wyglądają i czym różnią się te procesy.
Tomasz Soroka

Podsumowując - jakie korzyści płyną ze stosowania opisanego procesu?

  • Po pierwsze, oszczędzamy czas potrzebny na przygotowanie nowej wersji aplikacji. Przygotowanie nowego wydania dla każdej platformy zajmuje 15 minut. To oznacza, że dziennie oszczędzamy nawet 1-2 godziny cennego czasu developerów!
  • Unikamy błędów popełnionych podczas procesu przygotowania nowej wersji. Dzięki etapom testowania wszystkie błędy wyłapujemy odpowiednio wcześniej.
  • Szybko wyłapujemy wszelkiego rodzaju błędy na poziomie kompilacji – np. zmiana w kodzie na jednej platformie powoduje problem i brak kompilacji kodu na pozostałych (zmiany w część wspólnej w kodzie w aplikacjach cross platformowych).
  • Wyłapujemy wszystkie błędy na poziomie unit testów – mam na myśli błędy w logice, które powodują, że pewne komponenty aplikacji mogą przestać działać.
  • Poszczególne wersje aplikacji są automatycznie numerowane. Dzięki temu, jesteśmy w stanie dokładnie sprawdzić, jak zachowuje się każda wersja aplikacji na każdym etapie procesowym (testing, staging, produkcja).
  • Aplikacja jest automatycznie testowana – testy UI na jedną platformę mogą zająć nawet 4 godziny pracy jednego urządzenia. Przy założeniu, że aplikacja testuje się automatycznie na 10 urządzeniach oszczędzamy 40 godzin pracy testera! Dodatkowo, musimy mieć pewność, że tester nie będzie popełniał błędów.
  • Aplikacje są błyskawicznie dostępne dla wszystkich zainteresowanych osób w firmie, także dla klientów.  
  • Każda zmiana w kodzie aplikacji jest dokładnie śledzona - sprawdzamy, czy nie powoduje potencjalnych problemów. Jeśli tak jest, szybko widzimy miejsce błędu i poprawiamy kod.
  • Oszczędzamy czas klienta i dzięki zwinnemu procesowi zapewniamy wysokość jakość rozwiązania.
Jak widzicie, aktualnie stosowane przez nas metody developowania aplikacji charakteryzują się konkretnymi etapami procesu. Ich stosowanie polega na automatyzacji testów i wczesnej weryfikacji kodu. W kolejnym artykule opiszę, jak podłączyć aplikację pod serwer, który w znacznej części będzie budował ją autonomicznie.