Jakiś czas temu Microsoft udostępnił Azure DevOps. Z jednej strony, wygląda to na nowość. Z drugiej natomiast na coś znajomego. Przynajmniej dla ludzi znających VSTS lub VSOnline. Jest to zestaw pięciu narzędzi przydatnych w procesie wytwarzania oprogramowania. Od pomysłu, poprzez development, testowanie, aż po wdrażanie. Każdy z nich jest niezależny, ale również bardzo dobrze integruje się z pozostałymi. Czym są poszczególne składowe? Opisuję i objaśniam co to jest Azure DevOps.

Więcej i lepiej na ten temat znajdziesz na nowym blogu o tematyce sprawnego wytwarzania i dostarczania oprogramowania.
w poście „Czym jest Azure DevOps„

Boards

Jest to narzędzie do planowania prac i zarządzania zadaniami. Elektroniczna tablica scrumowa, czy kanbanowa. Pracując z poprzednimi wersjami, zawsze irytowała mnie toporność tego rozwiązania. Zwłaszcza w porównaniu do Jiry. Przepływ pracy i zadań wprawiał mnie w stan głębokiej irytacji, bo praca szła jak po grudzie.

Teraz wiem, że były ku temu dwa powody. Po pierwsze, nieznajomość narzędzia, a po drugie, niedopasowanie konfiguracji do modelu pracy zespołu. W związku z tym nie pracowaliśmy z optymalnie skonfigurowanym narzędziem. Teraz, patrząc na nowe ficzery oraz opcje konfiguracji, wiem, że można zrobić prawie wszystko, by pracowało się lepiej.

Pipelines

Ta część interesuje mnie najbardziej. To właśnie dzięki „potokom”, jak nazywa je Microsoft w Polskich tekstach, możemy konfigurować automatyczne procesy budowania i deploymentu aplikacji.

Siadając do tego po raz pierwszy, przepinając się z TeamCity, nie byłem w stanie zrobić praktycznie nic. Było to spowodowane, przede wszystkim innym podejściem do pracy z artefaktami, ale również nieznanym mi interfejsem. Z czasem, poznając założenia Azure Pipelies przekonałem się do tego narzędzia.

Co prawda w swoim prywatnym projekcie użyłem AppVeyora. Podejmując tę decyzję VSTS, było płatne. Dziś zdecydowałbym się na rozwiązanie Azure DevOps ze względu na 10 darmowych agentów dla projektów Open Source. Tak jak wybrał też Dotnetomaniak

Repos

Na pierwszy rzut oka nie ma zbyt wiele magii. Stworzysz sobie repozytorium w GIT lub w TFS. Jednak znajduje się tam pewna bardzo przydatna funkcjonalność, niewidoczna na pierwszy rzut oka. Jest to mechanizm obsługujący PullRequesty wraz z obsługą komentarzy. Mogący służyć jako bardzo przyjemne narzędzie do zdalnego CodeReview.

Artifacts

Tutaj stworzysz repozytorium dla Twoich pakietów NuGet, NPM, Maven itp. Po co? Przydaje się, gdy potrzebujesz prywatnego źródła pakietów, ale jest tu coś więcej. Możesz używać tego źródła jako proxy pomiędzy publicznym repozytorium NPM, czy NuGet. Dzięki czemu: 

1. Jeżeli pakiet zniknie z internetu, to wciąż jego kopia będzie na Twoim serwerze.
2. Pipelines będą działać szybciej, gdyż pakiety będą dostępne lokalnie.
3. Przy użyciu NPM masz możliwość podpięcia tylko jednego źródła na projekt, a używając Artifacts ten problem rozwiązuje się sam.

Test plans

Tool przydatny do zarządzania testami, którego, przyznam się szczerze, nigdy nie używałem.

Współpraca

Każdy z tych klocków jest niezależny, więc możesz je używać oddzielnie. Natomiast prawdziwą moc uzyskasz dopiero, korzystając z efektu synergii. Przykładowo, z poziomu tworzenia PullRequesta podepniesz taski z Boards.

Z poziomu zadań stworzysz brancza, a z builda bez problemu dodasz nowy pakiet do artefaktów.
Ponadto jestem bardzo, ale to bardzo mile zaskoczony tempem rozwoju tej platformy. Wszystkie nowe funkcje, plany, wersje opisują na blogu, więc jeżeli jesteś zainteresowany tematem, polecam śledzić.

Na koniec

Czy chcesz wiedzieć więcej w tym temacie? Jeżeli tak to zapraszam Cię na stronę https://deployadacemy.pl/10, gdzie pobierzesz poradnik z 10 wskazówkami jak deployować 100 razy dziennie.

A czy Ty miałeś styczność z Azure DevOps? Jeżeli tak to, jak oceniasz to narzędzie i w jakim scenariuszu je używałeś? A jeżeli nie to co chciałbyś się dowiedzieć?