Największym wyzwaniem w prowadzeniu projektów w i-systems jest fakt, że tworzymy dedykowane rozwiązania. Oczywiście korzystamy z własnego frameworka, ale ten wykorzystywany jest w sposób uniwersalny na bardzo niskiej warstwie (ORM, autorski silnik kompilowania szablonów, routing itp.). Dlatego każdy z naszych sklepów posiada własny branch (gałąź), na której rozwijana jest dedykowana funkcjonalność. Niemniej każda taka gałąź powstaje jako rozwidlenie od podstawowej gałęzi, którą nazywamy releasem. Współcześnie pracujemy tylko na jednej głównej gałęzi, ale jeszcze rok temu obowiązywały dwie. Jedna, dedykowana dla klientów integrujących się z platformą Allegro, druga – dla tych bez tej integracji. Obecnie zrezygnowaliśmy z rozwoju tej ostatniej, głównie z powodu niskiego zainteresowania taką wersją sklepu i koniecznym nakładzie pracy związanym z mergowaniem obu gałęzi przy okazji wydawania kolejnych wersji stabilnych. Release jest więc wersją podstawową sklepu, posiadającą uniwersalne moduły takie, jak: moduł zamówień, produktów, klientów oraz integracji z allegro. Branche to dedykowane klientom aplikacje z oczekiwaną funkcjonalnością.
Prowadzenie najmniejszych nawet projektów związanych z programowaniem wymaga podjęcia decyzji o systemie kontroli wersji oraz, co prawdopodobnie jest jeszcze ważniejsze, metodzie prowadzenia projektu.
Kilka lat temu zdecydowaliśmy się używać aplikacji bazaar, która oferuje funkcjonalności pozwalające nam zarządzać repozytorium projektu w sposób wygodny i optymalny. Gdy podejmowaliśmy tę decyzję, funkcjonalności aplikacji bazaar były unikatowe. Jednak wybór narzędzia był tylko pierwszym i najłatwiejszym krokiem. Dużo trudniejsze okazało się wypracowanie metodyki używania bazaar.
Dlaczego to robimy?
Utrzymywanie jednorodnego środowiska pozwala nam na pełną kontrolę nad bardzo ważnym aspektem aplikacji, jakim jest framework. Element ten jest kluczowy dla prawidłowego działania, choć z punktu widzenia użytkownika – niedostrzegalny. To jak silnik w samochodzie – niewidoczny pod maską zza kierownicy, ale bez niego jazda jest niemożliwa. Jedyną różnicą jest to, że silnik ten możemy poprawiać i usprawniać bez przerywania pracy.
Jednocześnie ciągle dynamicznie rozwijane środowisko, w którym działa nasz sklep pozwala na realizację coraz bardziej optymalnych i kompleksowych rozwiązań. Obecnie możemy uruchomić aplikację na serwerach dedykowanych, hostingach i usłudze cloud. Wykorzystujemy nowoczesne rozwiązania optymalizujące działanie sklepu, systemy monitorujące oraz wiele innych.
Aktualizacja oprogramowania w e-commerce
Nasz release wydawany jest nieregularnie, ale w oparciu o dwutygodniowe cykle sprintów zespołu SCRUM. Wcześniej zależało nam na tym, aby każdy sprint kończył się wydaniem nowej wersji, jednak system ten okazał się niepraktyczny. Stało się tak, bowiem aktualnie wykonywane zmiany, które trafić mają do release, wymagają czasu produkcji dłuższego niż jeden sprint. Oczywiście, zgodnie z metodyką SCRUM, każdy sprint kończy się wyprodukowaniem pewnej części gotowej aplikacji, jednak nie zawsze ta część ma wartość biznesową, w związku z tym nie warto dodawać jej do wersji stabilnej. Jednak mniej więcej raz w miesiącu wydawana jest kolejna wersja. Oczywiście, jak w każdym tego typu projekcie, wydawane są także hot fixy, czyli poprawki do błędów, które umknęły nam w czasie testów QA. Poprawki te wydawane są poza cyklem wydawania wersji stabilnych.
Branching i merging
Od głównej gałęzi sklepu budowane są repozytoria dedykowane klientom. Bazaar oferuje bardzo prostą metodę na utworzenie nowej wersji repozytorium, na podstawie aktualnej lokalnej wersji. Ta nowa wersja trafia do naszego portfela repozytoriów i rozwijana jest przez zespół programistów. Taki system pozornie może oznaczać, że wersja sklepu klienta jest aktualna tylko w momencie powstania, ponieważ rozwój wersji stabilnej następuje w innej gałęzi. Tak na szczęście nie jest. Gałęzie te bardzo często się przenikają. Nasi programiści bez większych problemów potrafią zaktualizować dowolną gałąź sklepu do wersji aktualnej. Wykonywane jest to przez proces fundamentalny dla zarządzania wersją czyli merge. Wbrew pozorom rozwiązywanie konfliktów w tym procesie (wynikających z faktu, że dwie gałęzie są rozwijane równolegle), nie jest zwykle bardzo skomplikowane. Wynika to przede wszystkim z architektury HMVC, w oparciu o którą rozwijana jest nasza aplikacja. Zapewnia to spore prawdopodobieństwo realizacji zmian tak, by nie mogły generować konfliktów ze zmianami w release.
Korzyści dla IT
Nie do przecenienia jest fakt, że każdy programista w i-systems może mieć i ma wpływ na procesy zachodzące w frameworku. Z jednej strony pozwala to na dużą swobodę i prostotę tworzenia oprogramowania, z drugiej strony wzmacnia poczucie odpowiedzialności za produkt. Metodyka tworzenia release, mam na myśli głównie proces akceptacyjny, pozwala także na rozwój umiejętności i nabywanie wiedzy wewnątrz zespołu. Każdy z naszych programistów może zaproponować nowe rozwiązanie, każde z tych rozwiązań jest analizowane przez zespół, co może rzucić zupełnie nowe światło. Pozwala to na bardzo sprawne i bezbolesne przekazywanie wiedzy.
Korzyści dla klienta
Rok w świecie internetu to epoka, nowości potrafią nadejść z dnia na dzień. Pilnie śledzimy zmiany wśród systemów, z którymi się integrujemy i reagujemy, gdy tylko jest to potrzebne. Stale także powiększamy portfel naszych możliwości. Na przykład w ostatnich dwunastu miesiącach stworzyliśmy integracje z sześcioma systemami kurierskimi (przy czym jeden z nich zmienił się w tym czasie dwukrotnie). Jednocześnie nadążamy za nowinkami technologicznym i dostarczymy klientowi najwyższej jakości, nowoczesny produkt dopasowany do jego potrzeb. Bieżące aktualizacje pozwalają też na wyeliminowanie problemów, podnoszą jakość produktu oraz zapewniają jego elastyczność w różnych środowiskach.
Tagi
