Nowy release i-systems właśnie ujrzał światło dzienne. Changelog (lista zmian) składa się z 38 pozycji. Jest wśród nich 11 poprawek takich funkcjonalności jak kupony, remarketing, płatności czy aukcje. Najważniejszą zmianą jest migracja na kontrolę wersji Git.
Dostosowanie releasa do kontroli wersji Git
Dotychczas wszystkie prace deweloperskie odbywały się w oparciu o system kontroli wersji Bazaar. Miał on jednak swoje niedoskonałości. Wśród nich była pewnego rodzaju archaiczność rozwiązań oraz, najbardziej uciążliwy dla nas, brak rozwoju i dostosowania do zmieniających się systemów i otoczenia. Tworząc kilkanaście releasów w ciągu roku oraz systemy o coraz większej strukturze, ten problem stawał się coraz większy z każdym kolejnym wydaniem aktualizacji oprogramowania i-systems. Często zespół IT musiał tworzyć własne rozwiązania w Bazaarze. W perspektywie długoterminowej jest to bardzo nieefektywne. Dlatego wszystkie wersje od poziomu 4.1 wzwyż będą funkcjonowały w oparciu o system kontroli wersji Git, a obecny release jest kluczowy dla procesu przejścia, gdyż zidentyfikował i rozwiązał wszystkie problemy i rozbieżności między Bazaarem i Git. Wspomniane rozbieżności dotyczyły m.in.: dodania odpowiednich skryptów, refaktoryzacji autoloada, czy dostosowania komponentów do lokalizacji w drzewie projektu.
Dlaczego Git?
System kontroli wersji podczas tworzenia oprogramowania eCommerce odpowiada za śledzenie zmian w plikach i kodzie oraz umożliwia przywołanie dowolnej wcześniejszej wersji. Dodatkowo możemy porównywać wersje i dowiedzieć się kto, kiedy i jakie konkretnie zmiany wprowadził. To kluczowe dla rozwijania systemów oraz bardzo pomocne w przypadku dużych projektów i zespołów. System Git powstał jako odpowiedź na wyzwania stojące przed zespołami IT, które pracują nad rozbudowanymi projektami. Git jest rozproszony, szybki, chroni przed błędami w repozytorium oraz eliminuje wszystkie błędy związane z CVS. Jego szczegółowe zalety to:
– możliwość śledzenia rozwoju projektu od samego początku do stanu aktualnego,
– możliwość powrotu do wybranej poprzedniej wersji,
– możliwość śledzenia zmian w kodzie w trybie offline,
– utrzymywanie każdego repozytorium jako oddzielnej gałęzi (branch), co przy projektach składających się z ponad 900 gałęzi jest dużym ułatwieniem w pracy,
– możliwość łączenia zmian dokonanych przez różne osoby w różnym czasie,
– budowa gałęzi umożliwiająca równoległą pracę kilku programistów nad kilkoma rozwiązaniami bez wzajemnego blokowania i kolidowania,
– szybka praca całego systemu kontroli wersji (odczuwalna przy dużych projektach),
– możliwość mergowania z każdego miejsca projekcie w każde inne,
– zapamiętywanie kompletnych obrazów zmian, a nie jak w przypadku innych systemów kontroli wersji, tylko poszczególnych zmian.
Dostosowanie releasa do kontroli wersji Git jest częścią długoterminowego planu rozwoju oprogramowania i-systems.
Przez continuous delivery…
Wizja rozwoju oprogramowania i-systems zakłada szybszy rozwój oraz bardziej efektywne dostosowywanie do wymagań rynku oraz do dedykowanych oczekiwań klientów. Dlatego wprowadzenie systemu kontroli wersji Git umożliwi sprawniejsze przejście do modelu continuous delivery. Continuous delivery to proces automatycznego wdrażania kodu do środowiska testowego, w którym można poddawać go kolejnym testom, tworzyć kolejne funkcjonalności, aż do uzyskania oczekiwanych rezultatów. Dopiero po zakończeniu serii testów, produkt jest przekazywany “na produkcję”, czyli przetestowane funkcjonalności zostają zaaplikowanie na serwer produkcyjny. Oczywiście mimo dużej automatyzacji procesów, wciąż cała decyzyjność pozostaje w zespole.
Intensywny proces tworzenia oprogramowanie nie ma wpływu na stabilność i bezpieczeństwo projektów. Metodę continuous delivery stosuje się w branży lotniczej, przemysłowej, bankowej czy w branży medycznej. Podobno NASA używa jej w przypadku sond kosmicznych. Dopiero po przejściu wszystkich testów i zatwierdzeniu przez zespół, oprogramowanie może być wykorzystywane przez klientów.
Poprzez automatyzację rutynowych zadań oraz szybką informację zwrotną, proces continuous delivery poprawia również satysfakcję programistów z wykonywanej przez nich pracy.
…do continuous integrations
W dłuższej perspektywie wszystkie zmiany mają doprowadzić do ciągłej integracji (continuous integration) oprogramowania i-systems. Ciągła integracja charakteryzuje się systematycznym dodawaniem bieżących zmian w kodzie do głównego repozytorium. Częstotliwość tych zmian może wynosić nawet do kilku dziennie. Optymalna częstotliwość w przypadku i-systems będzie jednak mniejsza. Najważniejsze zalety ciągłej integracji to: większa efektywność w łączeniu pracy w ramach projektów, możliwość prewencyjnego wykrywania ewentualnych błędów oraz stały dostęp do najnowszej wersji kodu. W praktyce continuous integration wspomaga zespół programistów poprzez zestaw narzędzi, które kompilują kod, tworzą builda, wykonują testy automatyczne oraz inne statyczne analizy kodu.
Wszystkie zmiany w procesie produkcji oprogramowania będą wprowadzane stopniowo, a dla klientów i-systems będą praktycznie niezauważalne – zmieni się sama organizacja części zespołu IT.
