Buddy, czyli nie taki DevOps straszny, jak go malują

– Używaliśmy wielu narzędzi do CI/CD i za każdym razem zadawaliśmy sobie pytanie: dlaczego, do cholery, to jest takie skomplikowane? Dlaczego automatyzacja nie może być prosta? Dlaczego za każdym razem, kiedy chcę coś zmienić, muszę prosić kogoś z DevOpsów, żeby mi to ogarnął? Czemu nie mogę zrobić sobie tego sam? – mówi Szymon Szczepankowski, CEO Buddy.

Te pytania doprowadziły zespół do stworzenia buddy.works, czyli narzędzia do automatyzacji procesów developerskich: od buildów, przez testy, po deploy na server. Rozmawiamy z jego twórcą – Szymonem Szczepankowskim, który opowiedział nam, w czym Buddy jest lepszy od popularnego Jenkinsa.

Szymon Szczepankowski. 33-letni przedsiębiorca SaaS z ponad 15-letnim doświadczeniem w IT. Web developer, założyciel Springloops.com – hostingu SVN z automatycznym deployem na serwer (5000 płatnych klientów z 120 krajów). Zwolennik szybkiego wdrażania nowych rozwiązań zgodnie z maksymą „done is better than perfect”. Rodowity Kaszub, od kilkunastu lat mieszkaniec Bielska-Białej, gdzie w 15-osobowym zespole tworzy i rozwija Buddy CI/CD – program do automatyzacji procesów dla web developerów.

Co wyróżnia Buddy’ego na tle konkurencji? Narzędzi do CI/CD jest mnóstwo.

Uprościliśmy cały proces do minimum. Przykładowo, jeśli chcesz skonfigurować atomic deployment, normalnie musiałbyś ogarnąć i zautomatyzować masę skryptów. U nas stawiasz pipeline, wybierasz z listy akcji Atomic Deployment, klikasz ‘Run’ i bang – działa. To samo Kubernetes – podajesz dane do klastra, komendy do odpalenia, kontener do aktualizacji i bang – działa. Możesz sobie bez problemu sam rozbudowywać pipeline o kolejne funkcje, krok po kroku wdrażając DevOpsy do procesu, a cała konfiguracja trwa dosłownie kilka minut.

Buddy to dzisiaj rozbudowane narzędzie, jestem ciekaw jak wyglądało na początku. Jaka była kluczowa funkcja na etapie MVP?

Podstawą zawsze jest deploy. To jest funkcja, której używają wszyscy developerzy – i równocześnie wstęp do bardziej rozbudowanych działań. Potem dołożyliśmy buildy, testy, notyfikacje, akcje monitorujące, więcej akcji devopsowych – wszystko według zapotrzebowania zgłaszanego przez userów. Obecnie mamy ponad 80 akcji z dedykowanymi integracjami pod AWS, Google, Azure, DigitalOcean, Kubernetesa, pełne wsparce Dockera, buildy Androida i obsługę praktycznie wszystkich najpopularniejszych języków i frameworków.

Jednak kluczową funkcją jest nasz UX. Żaden serwis CI/CD nie ma tak dopracowanego interfejsu jak nasz. Żaden nie jest tak prosty w obsłudze. Żadnego nie da się skonfigurować w 5-10 minut. Mówię to z pełną odpowiedzialnością za słowa. Dzięki temu każda osoba w firmie może korzystać z dobrodziejstw Gita i automatyzacji. To efekt kilkudziesięciu miesięcy pracy, testów i szukania nowych rozwiązań.

Większość firm od lat buduje swoje CI i Deployment na Pipline i Jenkinsie. Teraz jest trend, by tego zaprzestać. Dlaczego tak się dzieje?

Jenkins ma swoje należyte miejsce w historii. Myślisz “Continuous Integration” – mówisz “Jenkins”. Tak samo jak myślisz “konsola” – mówisz “Playstation”. Jednak Jenkins to od zawsze był kombajn kojarzący się z backendem, godzinami konfiguracji i milionem pluginów Dla wielu lżejszych środowisk wdrożenie Jenkinsa wydaje się zbyt karkołomne, chociaż uczciwie przyznaję, kolejne wersje starały się to poprawić. To jednak dało możliwość powstania wielu produktów alternatywnych, które, punktując wady Jenkinsa, wybiły się na jego tle.

Skoro używam Jenkinsa, skonfigurowałem go i poświęciłem na to czas, dlaczego powinienem przejść na Buddy’ego?

To jedno z najczęstszych pytań, które dostajemy na supporcie. Zazwyczaj odpowiadamy: “a dlaczego miałbym zmienić samochód na nowszy, jeżeli mój mercedes rocznik ‘86 dalej jeździ, tylko wymaga okresowej konserwacji i nie można nim za bardzo szaleć?”. Nikogo nie obrażając, po prostu tak jest. Buddy jest szybszy, łatwiejszy w obsłudze. Docker gwarantuje stabilność. Możesz go modować i dokładać kolejne elementy, jak w Need for Speedzie. Spróbuj zrobić to samo w swoim wiekowym mercedesie.

Tak samo TeamCity, Codeship, Travis, GitLab – część z tych narzędzi zaczęła przed Dockerem, część dodała obsługę kontenerów później, ale żadne nie jest tak lekkie i szybkie, jak nasz soft. U nas YAML jest wyborem dla zaawansowanych userów – w innych narzędziach skrypty są koniecznością. To znacznie podwyższa barierę wejścia.

Oferty pracy z

Załóżmy, że chcę przejść z Jenkinsa na Buddy. Co zrobić, żeby to przejście było płynniejsze?

Nie rezygnować z Jenkinsa od razu, tylko używać go równolegle z Buddym. Z czasem elastyczność i wszechstronność naszego rozwiązania zadziała i zorientujesz się, że więcej robimy w Buddym na samych akcjach niż Jenkinsem. Mamy mnóstwo klientów, którzy mówią, że nie byliby w stanie wrócić do poprzedniego softu po przesiadce na Buddy’ego – za bardzo pokochali nasz UX.

Trafiacie do tych samych klientów, co Jenkins? Do tych, którzy korzystają właśnie z tych narzędzi, czy do tych, którzy jeszcze nie korzystali z żadnego z nich?

To jest coś, na co sami cały czas staramy się odpowiedzieć. Zamknęliśmy potężne możliwości w prostej w użyciu formie. To może być mylące dla bardziej zaawansowanych użytkowników, którzy mogą na pierwszy rzut oka nie doceniać potencjału Buddy’ego – powiedzą: „hej patrzcie jakie to kolorowe, jak się wszystko kręci, to na pewno jakaś wydmuszka”. Dla nich dodaliśmy obsługę YAMLa, żeby nie musieli wychodzić z terminala.

Z drugiej strony, wiemy, że jest cała masa firm, które w ogóle nie wdrażały DevOpsów albo mają je w mocno ograniczonej formie (np. tylko deploy na produkcję). One z kolei, widząc taką mnogość funkcji na starcie, mogą wystraszyć się implementacji. Uchwycić tutaj złoty środek jest trudno. Jest to coś co cały czas optymalizujemy: dodajemy sugestie akcji, optymalizujemy onboarding i cały czas służymy pomocą na supporcie.

Jeszcze przed Buddy wypuściliście proste narzędzie do hostowania repozytoriów SVN z funkcją transferu kodu na serwery FTP – springloops.com. Jego sukces zainspirował Was do stworzenia Buddy’ego?

Nasza praca nad produktami zaczęła się w połowie ubiegłej dekady, kiedy królem kontroli wersji było Subversion. Wypuściliśmy springloops.com, temat fajnie chwycił, bo udało się nam w stosunkowo krótkim czasie osiągnąć pułap paru tysięcy płatnych klientów. Z czasem nastąpiła dockerowa rewolucja i poczuliśmy, że możemy znacznie więcej. Nie chcąc wywracać klientom wszystkiego do góry nogami, wypuściliśmy Buddy’ego jako niezależny produkt. Zrobiło się miło: serwis rośnie kilkakrotnie szybciej niż Springloops.

Zobacz też

Wywiady Czy na pewno jesteś samodzielnym developerem? O kompetencjach w 2021 roku

Jaki sposób zarabiania na swoim produkcie wybraliście i dlaczego?

Jak każdy SaaS zarabiamy na opłatach abonamentowych. W ogóle SaaS to trudny biznes, który rzadko kiedy odnosi sukces z dnia na dzień. To codzienna, mozolna rzeźba: developowanie nowych funkcji, czyszczenie bugów, dopieszczanie interfejsu, cotygodniowe mailingi, content marketing, no i support 24 godziny na dobę, który charakteryzuje się tym, że niemal każdy przypadek jest inny i nierzadko wymaga zaangażowania developerów przy rozwiązywaniu problemów. SaaS ma za to jedną niezaprzeczalną zaletę: zarabia od samego początku.

Czego użytkownicy Buddy’ego mogą spodziewać się za kilka tygodni, miesięcy? Jakie macie plany na przyszłość?

Obecnie naszym planem jest stworzenie inteligentnego systemu, który pozwoli uruchamiać aplikacje bezpośrednio z repozytorium, bez potrzeby stawiania i konfiguracji serwerów. Ma on automatycznie rozpoznać typ aplikacji (np. WordPress), zbudować ją i dostarczyć gotową do uruchomienia w przeglądarce. Nazywamy to Sandboxami. Mamy jeszcze parę innych pomysłów – na pewno jeszcze o nas usłyszycie.

Jeśli do codziennej pracy także używacie wartych polecenia narzędzi, które stworzyli Polacy, dajcie znać w komentarzach. Chętnie dowiemy się więcej na temat historii powstania takich produktów. Przy okazji, polecamy naszą rozmowę z twórcą Fefaq, aplikacji z pytaniami rekrutacyjnymi dla frontendowców.