Planujesz wdrożenie oprogramowania Atlassian (Jira, Confluence)? Nie chcesz popełnić poważnych błędów w projektowaniu, które potem trzeba będzie rozwiązywać w ostatniej chwili?
W takim razie trafiłeś we właściwe miejsce – rozważamy wdrożenie Atlassian Jira + Confluence w korporacji, biorąc pod uwagę różne aspekty techniczne.
Dzień dobry, jestem właścicielem produktu w RSHB i odpowiadam za rozwój Systemu Zarządzania Cyklami Życia (SZCZŻ), opartego na produktach oprogramowania firmy Atlassian Jira i Confluence.
W tym artykule opiszę techniczne aspekty budowy SZCZŻ. Artykuł będzie przydatny dla wszystkich, którzy planują wdrożenie lub zajmują się rozwojem Atlassian Jira i Confluence w środowisku korporacyjnym. Nie wymaga specjalistycznej wiedzy i jest dostosowany do osób rozpoczynających przygodę z produktami firmy Atlassian. Będzie przydatny dla administratorów, właścicieli produktu, kierowników projektów, architektów, wszyscy, którzy planują wdrożenie systemów opartych na oprogramowaniu Atlassian.
Wprowadzenie
W artykule omówimy techniczne zagadnienia związane z wdrożeniem Systemu Zarządzania Cyklami Życia (SZCZŻ) w środowisku korporacyjnym. Najpierw zdefiniujemy, co to właściwie oznacza.
A co oznacza rozwiązanie korporacyjne?
Oznacza to rozwiązanie:
- Skalowalne. W przypadku wzrostu obciążenia istnieje techniczna możliwość zwiększenia mocy systemu. Rozróżnia się skalowanie poziome i pionowe – przy skalowaniu pionowym zwiększa się moc serwerów, przy skalowaniu poziomym zwiększa się liczbę serwerów działających w systemie.
- Odporne na awarie. System pozostanie dostępny nawet w przypadku awarii jednego elementu. W ogólnym przypadku dla systemów korporacyjnych odporność na awarie nie jest wymagana, ale będziemy rozważać właśnie takie rozwiązanie. W naszej systemie planujemy setki konkurencyjnych użytkowników, a przestoje będą niezwykle krytyczne.
- Wspierane. Rozwiązanie musi być wspierane przez dostawcę. Oprogramowanie bez wsparcia powinno być zastąpione własnymi rozwiązaniami lub innym oprogramowaniem z wsparciem.
- Instalacja Zarządzane samodzielnie (On-premise). Zarządzane samodzielnie - to możliwość instalacji oprogramowania nie w chmurze, a na własnych serwerach. Mówiąc precyzyjniej, chodzi o wszystkie opcje instalacji, które nie są SaaS. W tym artykule będziemy omawiać tylko opcje instalacji typu zarządzane samodzielnie.
- Możliwość niezależnego rozwijania i testowania. Aby zorganizować przewidywalne zmiany w systemie, wymagane są oddzielne systemy do rozwijania (zmian w samym systemie), testowania (Staging) oraz produkcyjny system do pracy użytkowników.
- Inne. Obsługuje różne scenariusze uwierzytelniania, wspiera logi audytowe, ma konfigurowalny model ról itd.
To podstawowe elementy rozwiązań korporacyjnych i, niestety, często są pomijane przy projektowaniu systemu.
Co to jest System zarządzania cyklem życia (SZC)?
Krótko mówiąc, w naszym przypadku to Atlassian Jira i Atlassian Confluence — systemy, które dostarczają narzędzi do organizacji pracy zespołowej. System nie "narzuca" zasad organizacji pracy, lecz oferuje różnorodne narzędzia, w tym Scrum, tablice Kanban, model kaskadowy, skalowalny Scrum itp.
Nazwa SZC nie jest terminem branżowym ani powszechnie używanym pojęciem, to po prostu nazwa systemu w naszym Banku. SZC nie jest dla nas systemem śledzenia błędów, systemem zarządzania incydentami ani systemem zarządzania zmianami.
Co obejmuje wdrożenie?
Wdrożenie rozwiązania składa się z wielu pytań technicznych i organizacyjnych:
- Przydzielenie zasobów technicznych.
- Zakup oprogramowania.
- Stworzenie zespołu do wdrożenia rozwiązania.
- Instalacja i konfiguracja rozwiązania.
- Opracowanie architektury rozwiązania. Model ról.
- Opracowanie dokumentacji eksploatacyjnej, w tym instrukcji, regulaminów, projektu technicznego, regulacji itd.
- Zmiana procesów firmy.
- Stworzenie zespołu wsparcia. Opracowanie SLA.
- Szkolenie użytkowników.
- Inne.
W tym artykule omówimy techniczne aspekty wdrożenia, bez szczegółów dotyczących składników organizacyjnych.
Cechy Atlassian.
Firma Atlassian jest liderem w wielu segmentach:
(Liderstwo wynika z udanego zakupu AgileCraft z jego rozwiązaniem w chmurze)
Produkty firmy Atlassian mają wszystkie niezbędne funkcje korporacyjne. Zauważam następujące cechy:
- Rozwiązania Atlassian opierają się na serwerze aplikacji Java Tomcat. Oprogramowanie Apache Tomcat jest częścią instalacji Atlassian i nie można zmienić wersji Apache Tomcat, który jest zainstalowany w oprogramowaniu Atlassian, nawet jeśli ta wersja jest przestarzała i zawiera luki w zabezpieczeniach. Jedyną możliwością jest czekanie na aktualizacje od Atlassian, z nowszą wersją Apache Tomcat. Obecnie, na przykład, w aktualnych wersjach Jira jest Apache Tomcat 8.5.42, a w Confluence jest Apache Tomcat 9.0.33.
- Interfejs użytkownika jest wygodny, wdrażane są najlepsze praktyki dostępne na rynku dla tej klasy oprogramowania.
- Całkowicie konfigurowalne rozwiązanie. Dzięki modyfikacjom można wdrożyć jakiekolwiek zmiany w podstawowej funkcjonalności dla użytkownika.
- Rozbudowany ekosystem. Istnieje kilka setek partnerów: , w tym 16 partnerów w Rosji. Przez partnerów w Rosji można zakupić oprogramowanie Atlassian, wtyczki, przejść szkolenie. To partnerzy opracowują i wspierają większość wtyczek.
- Sklep z aplikacjami (wtyczki): . Wtyczki znacznie rozszerzają funkcjonalność oprogramowania Atlassian. Podstawowa funkcjonalność oprogramowania Atlassian jest dość skromna, praktycznie w każdej sytuacji pojawia się potrzeba instalacji dodatkowych wtyczek, bezpłatnie lub za dodatkowe pieniądze. Dlatego koszty oprogramowania mogą okazać się znacznie wyższe niż pierwotnie oceniano.
Obecnie w sklepie opublikowano kilka tysięcy wtyczek, z których prawie tysiąc została przetestowana i zwalidowana w programie Data Center approved apps. Takie wtyczki można uznać za stabilne i odpowiednie do użycia w obciążonych systemach.
Zalecam dokładne zaplanowanie wtyczek, ponieważ ma to ogromny wpływ na koszt rozwiązania, wiele z wtyczek może prowadzić do niestabilności systemu, a producent wtyczki nie udzieli wsparcia w rozwiązaniu problemu. - Szkolenia i certyfikacje:
- Obsługiwane są mechanizmy SSO, SAML 2.0.
- Wsparcie dla skalowalności i odporności na awarie istnieje tylko w edycjach Data Center. Taka edycja po raz pierwszy pojawiła się w 2014 roku (Jira 6.3). Funkcjonalność edycji Data Center jest stale rozszerzana i udoskonalana (na przykład możliwość instalacji na pojedynczym węźle pojawiła się dopiero w 2020 roku). Podejście do wtyczek w edycjach Data Center znacznie zmieniło się w 2018 roku wraz z wprowadzeniem aplikacji zatwierdzonych przez Data Center.
- Koszt wsparcia. Koszt wsparcia od dostawcy jest praktycznie równy pełnemu kosztowi licencji oprogramowania. Przykład obliczenia kosztu licencji przedstawiono poniżej.
- Brak wersji Long Term. Są tak zwane , ale podobnie jak wszystkie inne wersje, są wspierane przez 2 lata. Z tą różnicą, że dla wersji Enterprise wydawane są jedynie poprawki, bez dodawania nowej funkcjonalności.
- Rozszerzone opcje wsparcia (za dodatkową opłatą).
- Wspieranych jest kilka rodzajów baz danych. Oprogramowanie Atlassian dostarczane jest z bezpłatną bazą danych H2, jednak ta baza danych nie jest zalecana do użytku produkcyjnego. Do użytku produkcyjnego wspierane są następujące bazy danych: Amazon Aurora (tylko Data Center) PostgreSQL, Azure SQL, MySQL, Oracle DB, PostgreSQL, MS SQL Server. Istnieją ograniczenia dotyczące wspieranych wersji i często wspierane są jedynie starsze wersje, ale dla każdej bazy danych jest dostępna wersja z wsparciem dostawcy:
,
.
Architektura techniczna
Wyjaśnienia do schematu:
- Na schemacie przedstawiona jest realizacja w naszym banku, ta konfiguracja jest podana jako przykład i nie jest rekomendowana.
- nginx zapewnia funkcjonalność reverse-proxy zarówno dla Jira, jak i dla Confluence.
- Odporność bazy danych implementowana jest za pomocą środków dostarczanych przez samą bazę danych.
- Przenoszenie zmian między środowiskami odbywa się przy użyciu wtyczki Configuration Manager for Jira.
- AppSrv na schemacie – to nasz własny serwer aplikacji do raportowania, nie wykorzystuje oprogramowania Atlassian.
- Baza danych EasyBI została stworzona do budowania kostek i raportowania przy użyciu wtyczki eazyBI Reports and Charts for Jira.
- Usługa Confluence Synchrony (komponent umożliwiający jednoczesne edytowanie dokumentów) nie jest wydzielona jako oddzielna instalacja i uruchamiana jest wspólnie z Confluence, na tym samym serwerze.
Licencjonowanie
Pytania dotyczące licencjonowania Atlassian zasługują na osobny artykuł, tutaj wspomnę jedynie o ogólnych zasadach.
Główne pytania, z którymi się spotkaliśmy, dotyczą licencjonowania edycji Data Center. Cechy licencjonowania dla edycji Server i Data Center:
- Licencja dla edycji Server jest bezterminowa, a nabywca może korzystać z oprogramowania nawet po jej wygaśnięciu. Jednak po wygaśnięciu licencji nabywca traci prawo do wsparcia produktu oraz aktualizacji oprogramowania do najnowszych wersji.
- Licencjonowanie odbywa się na podstawie liczby użytkowników w systemie „JIRA Users” na poziomie globalnym. Nie ma przy tym znaczenia, czy użytkownicy korzystają z systemu, czy nie — nawet jeśli użytkownicy nigdy się nie zalogowali, wszyscy będą wliczani do liczby licencjonowanych użytkowników. W przypadku przekroczenia liczby licencjonowanych użytkowników rozwiązaniem będzie usunięcie uprawnienia „JIRA Users” od niektórych użytkowników.
- Licencja na Data Center w praktyce jest subskrypcją. Wymagana jest roczna opłata za licencję. Po upływie terminu korzystanie z systemu zostanie zablokowane.
- Koszt licencji może się zmieniać w zależności od czasu. Jak pokazuje praktyka, zazwyczaj w górę, i to może być znaczne. Dlatego jeśli w tym roku licencje są w danej kwocie, to w następnym roku cena licencji może wzrosnąć.
- Licencjonowanie odbywa się na podstawie użytkowników w zakresie tier (na przykład, poziom 1001-2000 użytkowników). Istnieje możliwość przejścia na wyższy tier, za dodatkową opłatą.
- W przypadku przekroczenia liczby licencjonowanych użytkowników nowi użytkownicy będą tworzeni bez prawa do logowania się do systemu („JIRA Users” na poziomie globalnym).
- Wtyczki można licencjonować jedynie na tę samą liczbę użytkowników, co główne oprogramowanie.
- Licencjonować wymagane jest jedynie dla instalacji produkcyjnych, dla pozostałych można uzyskać licencję dewelopera: .
- Aby zakupić wsparcie, wymagana jest zakup odnowienia wsparcia oprogramowania — koszt wynosi około 50% ceny początkowego oprogramowania. Ta możliwość nie jest dostępna dla Data Center i nie obejmuje wtyczek — za ich wsparcie trzeba będzie płacić pełną roczną stawkę.
Tak więc roczne wsparcie oprogramowania kosztuje ponad 50% całkowitej ceny oprogramowania w przypadku edycji Server i 100% w przypadku edycji Data Center — to znacznie więcej niż u większości innych dostawców. Moim zdaniem, to istotna wada modelu biznesowego Atlassian.
Szczegóły przejścia z edycji Server na Data Center:
- Przejście z edycji Server na Data Center jest płatne. Koszt można znaleźć tutaj .
- Przy przejściu z edycji Server na Data Center nie jest wymagana opłata za zmianę edycji wtyczek — wtyczki dla edycji Server będą działać. Jednak konieczne będzie odnawianie licencji dla wtyczek dla edycji Data Center.
- Możesz używać wtyczek, dla których nie ma wersji do edycji Data Center. Oczywiście takie wtyczki mogą działać nieprawidłowo, dlatego lepiej wcześniej przewidzieć alternatywy dla takich wtyczek.
- Przejście na edycję Data Center odbywa się poprzez instalację nowej licencji. Licencja dla edycji Server nadal pozostaje dostępna.
- Nie ma żadnych różnic funkcjonalnych między edycjami Data Center i Server dla użytkowników, wszystkie różnice dotyczą funkcji administrowania i technicznych możliwości instalacji.
- Koszt oprogramowania i wtyczek różni się dla edycji Server i Data Center. Różnica w kosztach często wynosi mniej niż 5% (nieistotne). Przykład obliczenia kosztów podany jest poniżej.
Zakres funkcjonalny wdrożenia
Podstawowa dystrybucja oprogramowania Atlassian zawiera ogromną liczbę możliwości, ale często możliwości oferowane przez system są znacznie niewystarczające. Czasami nawet najprostsze funkcje są niedostępne w podstawowej dystrybucji, dlatego prawie zawsze do wdrożenia potrzebne są wtyczki. Dla systemu Jira używamy następujących wtyczek (zdjęcie klikane):
Dla systemu Confluence używamy następujących wtyczek (zdjęcie klikane):
Komentarze do tabel z wtyczkami:
- Wszystkie ceny podano na podstawie 2000 użytkowników;
- Podano ceny na podstawie wskazanych cen , rzeczywisty koszt (ze zniżkami) jest niższy;
- Jak widać, całkowita kwota praktycznie nie różni się między edycjami Data Center i Server;
- Do użytku wybrano tylko wtyczki wspierające edycję Data Center. Pozostałe wtyczki wykluczyliśmy z planów, aby zapewnić stabilność systemu.
Funkcjonalność krótko opisana jest w kolumnie Komentarz. Dodatkowe wtyczki rozszerzyły funkcjonalność systemu:
- Dodano kilka narzędzi wizualnych;
- Ulepszono mechanizmy integracyjne;
- Dodano narzędzia do projektów według modelu waterfall;
- Dodano narzędzia do skalowalnego Scrum, aby zorganizować pracę dużych zespołów projektowych;
- Dodano funkcjonalność do rejestrowania czasu;
- Dodano narzędzia do automatyzacji operacji i konfigurowania rozwiązania;
- Dodano funkcjonalność do uproszczenia i automatyzacji administracji rozwiązaniem.
Dodatkowo używamy Aplikacja ta umożliwia edytowanie plików w zewnętrznych aplikacjach (MS Office) i zwracanie ich z powrotem do Confluence (check-in).
Aplikacja dla stacji roboczych użytkowników (gruby klient) ALM Works Jira Client postanowiono nie używać z powodu słabej obsługi ze strony dostawcy i negatywnych opinii.
Dla integrowania z MS Project używamy własnoręcznie napisanej aplikacji, która pozwala na aktualizację statusów issue w MS Project z Jira i odwrotnie. W przyszłości, do tych samych celów, planujemy użyć płatnego wtyczki. , która jest instalowana jako dodatek do MS Project.
Integracja zewnętrznych aplikacji jest realizowana przez Application Links. W przypadku aplikacji Atlassian integracje są wstępnie skonfigurowane i działają od razu po ustawieniu, na przykład można wyświetlić na stronie w Confluence informacje o issue w Jira.
Dostęp do serwerów Jira i Confluence jest realizowany za pomocą REST API: .
SOAP i API XML-RPC są przestarzałe i niedostępne w nowych wersjach do użycia.
Podsumowanie
Zatem przyjrzeliśmy się technicznym aspektom wdrożenia systemu opartego na produktach Atlassian. Zaproponowane rozwiązanie stanowi jedno z możliwych rozwiązań i dobrze nadaje się do środowiska korporacyjnego.
Proponowane rozwiązanie jest skalowalne, odporne na awarie, zawiera trzy środowiska do organizacji rozwoju i testów, zawiera wszystkie niezbędne elementy do współpracy w systemie oraz oferuje szeroki wachlarz narzędzi do zarządzania projektami.
Z chęcią odpowiem na pytania w komentarzach.
Źródło: habr.com
