Beplan u om Atlassian-sagteware (Jira, Confluence) te implementeer? Wil jy nie wrede ontwerpfoute maak wat dan op die laaste oomblik opgelos moet word nie?
Dan is jy hier - ons oorweeg die implementering van Atlassian Jira + Confluence in 'n korporasie, met inagneming van verskeie tegniese aspekte.
Hallo, ek is 'n produkeienaar by RSHB en is verantwoordelik vir die ontwikkeling van die Lewensiklusbestuurstelsel (LCMS) gebou op Atlassian Jira en Confluence sagteware produkte.
In hierdie artikel sal ek die tegniese aspekte van die bou van 'n LCMS beskryf. Die artikel sal nuttig wees vir enigiemand wat beplan om Atlassian Jira en Confluence in 'n korporatiewe omgewing te implementeer of te ontwikkel. Die artikel vereis nie spesiale kennis nie en is ontwerp vir 'n aanvanklike vlak van vertroudheid met Atlassian-produkte. Die artikel sal nuttig wees vir administrateurs, produkeienaars, projekbestuurders, argitekte en almal wat beplan om stelsels te implementeer wat op Atlassian-sagteware gebaseer is.
Inleiding
Die artikel sal die tegniese kwessies van die implementering van 'n Lewensiklusbestuurstelsel (LCMS) in 'n korporatiewe omgewing bespreek. Kom ons definieer eers wat dit beteken.
Wat is 'n ondernemingsoplossing?
Dit beteken die oplossing:
- Skaalbaar. In die geval van 'n toename in vrag, is daar 'n tegniese moontlikheid om die kapasiteit van die stelsel te verhoog. Afsonderlike horisontale en vertikale skalering - met vertikale skalering word die kapasiteit van bedieners verhoog, met horisontale skaal word die aantal bedieners vir die stelselwerking verhoog.
- Foutveilig. Die stelsel sal beskikbaar bly as een element misluk. Oor die algemeen vereis korporatiewe stelsels nie fouttoleransie nie, maar ons sal net so 'n oplossing oorweeg. Ons beplan om 'n paar honderd mededingende gebruikers in die stelsel te hê, en stilstand sal baie krities wees.
- Ondersteun. Die oplossing moet deur die verkoper ondersteun word. Nie-ondersteunde sagteware moet vervang word deur interne ontwikkeling of ander ondersteunde sagteware.
- installasie Selfbestuur (op uitgangspunt). Selfbestuur is die vermoë om sagteware nie in die wolk te installeer nie, maar op jou eie bedieners. Om meer presies te wees, is dit alles nie-SaaS-installasie-opsies. In hierdie artikel sal ons slegs selfbestuurde installasie-opsies oorweeg.
- Moontlikheid van onafhanklike ontwikkeling en toetsing. Om voorspelbare veranderinge in die stelsel te organiseer, word 'n aparte stelsel vir ontwikkeling (veranderinge in die stelsel self), 'n toetsstelsel (Staging) en 'n produktiewe stelsel vir gebruikers vereis.
- Ander. Ondersteun verskeie verifikasie-scenario's, ondersteun ouditlogboeke, het 'n pasgemaakte rolmodel, ens.
Dit is die hoofelemente van ondernemingsoplossings en ongelukkig word dit dikwels vergeet wanneer 'n stelsel ontwerp word.
Wat is 'n lewensiklusbestuurstelsel (LCMS)?
Kortom, in ons geval is dit Atlassian Jira en Atlassian Confluence - 'n stelsel wat gereedskap verskaf om spanwerk te organiseer. Die stelsel "dring" nie reëls op vir die organisering van werk nie, maar bied 'n verskeidenheid gereedskap vir werk, soos Scrum, Kanban-borde, 'n watervalmodel en skaalbare Scrum, ens.
Die naam LCMS is nie 'n bedryfsterm of 'n algemene term nie, dit is bloot die naam van die stelsel in ons Bank. LCMS vir ons is nie 'n foutopsporingstelsel nie, dit is nie 'n Voorvalbestuurstelsel en 'n Veranderingbestuurstelsel nie.
Wat sluit implementering in?
Die implementering van die oplossing bestaan uit baie tegniese en organisatoriese kwessies:
- Toewysing van tegniese vermoëns.
- Aankoop van sagteware.
- Skep van 'n span om die oplossing te implementeer.
- Installasie en konfigurasie van die oplossing.
- Oplossingsargitektuurontwikkeling. rolmodel.
- Ontwikkeling van operasionele dokumentasie, insluitend instruksies, regulasies, tegniese ontwerp, regulasies, ens.
- Verandering van maatskappy prosesse.
- Skep van 'n ondersteuningspan. SLA ontwikkeling.
- Gebruikersopleiding.
- Ander.
In hierdie artikel sal ons die tegniese aspekte van implementering oorweeg, sonder besonderhede oor die organisatoriese komponent.
Beskik oor Atlassian
Atlassian is 'n leier in baie segmente:
(Leierskap as gevolg van die suksesvolle verkryging van AgileCraft met sy wolkoplossing)
Atlassian se produkte het al die ondernemingskenmerke wat jy nodig het. Ek sal op die volgende kenmerke let:
- Atlassian-oplossings is gebaseer op die Java Tomcat-webbediener. Apache Tomcat-sagteware is by Atlassian-sagteware ingesluit, as deel van die installasie kan jy nie die weergawe van Apache Tomcat wat met Atlassian-sagteware geïnstalleer is verander nie, selfs al is die weergawe verouderd en bevat kwesbaarhede. Die enigste opsie is om te wag vir 'n opdatering van Atlassian met 'n nuwer weergawe van Apache Tomcat. Nou, byvoorbeeld, het die huidige weergawes van Jira Apache Tomcat 8.5.42, en Confluence het Apache Tomcat 9.0.33.
- Gerieflike koppelvlak, die beste praktyke wat op die mark beskikbaar is vir hierdie klas sagteware word geïmplementeer.
- Volledig aanpasbare oplossing. Met verbeterings kan u enige verandering in die basiese funksionaliteit vir die gebruiker implementeer.
- Ontwikkelde ekosisteem. Daar is 'n paar honderd vennote: , insluitend 16 vennote in Rusland. Dit is deur vennote in Rusland dat u Atlassian-sagteware, inproppe kan koop en opleiding kan kry. Dit is die vennote wat die meeste van die plugins ontwikkel en onderhou.
- App Store (inproppe): . Inproppe verbeter die funksionaliteit van Atlassian-sagteware aansienlik. Die basiese funksionaliteit van Atlassian-sagteware is redelik beskeie, vir byna enige taak word dit nodig om addisionele inproppe gratis of vir ekstra geld te installeer. Daarom kan sagteware koste aansienlik hoër wees as wat oorspronklik geraam is.
Tot op datum is 'n paar duisend inproppe in die winkel gepubliseer, byna 'n duisend van hulle is getoets en bekragtig onder die datasentrum-goedgekeurde toepassingsprogram. Sulke inproppe kan as stabiel beskou word en geskik vir gebruik in besige stelsels.
Ek raai u aan om die kwessie van die beplanning van plugins noukeurig te benader, dit beïnvloed die koste van die oplossing grootliks, baie van die plugins kan lei tot stelsel onstabiliteit en die inpropvervaardiger bied nie ondersteuning om die probleem op te los nie. - Opleiding en sertifisering:
- SSO, SAML 2.0 meganismes word ondersteun.
- Ondersteuning vir skaalbaarheid en fouttoleransie is slegs beskikbaar in Datasentrum-uitgawes. Hierdie uitgawe het die eerste keer in 2014 verskyn (Jira 6.3). Die funksionaliteit van die datasentrum-uitgawes word voortdurend uitgebrei en verbeter (die moontlikheid van 'n enkele nodus-installasie het byvoorbeeld eers in 2020 verskyn). Die benadering tot inproppe vir Datasentrum-uitgawes het baie verander in 2018 met die bekendstelling van Datasentrum-goedgekeurde toepassings.
- Ondersteuningskoste. Die koste van ondersteuning van die verkoper is amper gelyk aan die volle koste van sagtewarelisensies. 'n Voorbeeld van die berekening van die koste van lisensies word hieronder gegee.
- Gebrek aan langtermyn vrystellings. Daar is sg , maar hulle, soos alle ander weergawes, word vir 2 jaar ondersteun. Met die verskil dat slegs regstellings vir Enterprise-weergawes vrygestel word, sonder om nuwe funksionaliteit by te voeg.
- Uitgebreide ondersteuningsopsies (vir bykomende geld).
- Verskeie variante van DBMS word ondersteun. Atlassian kom met 'n gratis H2-databasis, wat nie aanbeveel word vir produktiewe gebruik nie. Die volgende DBBS word vir produktiewe gebruik ondersteun: Amazon Aurora (slegs datasentrum) PostgreSQL, Azure SQL, MySQL, Oracle DB, PostgreSQL, MS SQL Server. Daar is beperkings op ondersteunde weergawes en dikwels word net ouer weergawes ondersteun, maar vir elke DBMS is daar 'n weergawe met verskafferondersteuning:
,
.
Tegniese argitektuur
Verduidelikings vir die skema:
- Die diagram toon die implementering in ons Bank, hierdie konfigurasie word as 'n voorbeeld gegee en word nie aanbeveel nie.
- nginx bied omgekeerde proxy-funksionaliteit vir beide Jira en Confluence.
- Die fouttoleransie van 'n DBBS word deur middel van die DBBS geïmplementeer.
- Die oordrag van veranderinge tussen omgewings word gedoen met behulp van die Configuration Manager for Jira-inprop.
- AppSrv in die diagram is 'n inheemse verslagdoeningtoepassingsbediener, gebruik nie Atlassian-sagteware nie.
- Die EasyBI-databasis is geskep vir die bou van kubusse en verslagdoening met behulp van die eazyBI Reports and Charts for Jira-inprop.
- Die Confluence Synchrony-diens ('n komponent wat gelyktydige redigering van dokumente toelaat) word nie in 'n aparte installasie geskei nie en loop saam met Confluence, op dieselfde bediener.
lisensiëring
Atlassian-lisensiekwessies verdien 'n aparte artikel, hier sal ek slegs algemene beginsels noem.
Die belangrikste kwessies wat ons ontmoet het, is die kwessies van lisensiëring van datasentrum-uitgawes. Lisensiëringskenmerke vir bediener- en datasentrum-uitgawes:
- Die lisensie vir die Server-uitgawe is ewigdurend en die kliënt kan die sagteware gebruik selfs nadat die lisensie verval het. Maar nadat die lisensie verval, verloor die koper die reg om produkondersteuning te ontvang en die sagteware op te dateer na die nuutste weergawes.
- Lisensiëring is gebaseer op die aantal gebruikers in die 'JIRA Users' globale toestemmingstelsel. Dit maak nie saak of hulle die stelsel gebruik of nie - selfs al het gebruikers nog nooit by die stelsel aangemeld nie, sal alle gebruikers vir die lisensie in ag geneem word. As die aantal gelisensieerde gebruikers oorskry word, is die oplossing om die 'JIRA-gebruikers'-toestemming van sommige van die gebruikers te verwyder.
- Die datasentrumlisensie is eintlik 'n intekening. 'n Jaarlikse lisensiefooi word vereis. Met die verstryking van die termyn sal werk met die stelsel geblokkeer word.
- Die koste van lisensies kan met verloop van tyd verander. Soos die praktyk toon, in 'n groot manier en, miskien, aansienlik. Dus, as jou lisensies vanjaar een bedrag kos, kan die koste van lisensies volgende jaar styg.
- Lisensiëring word deur gebruikers volgens vlak gedoen (byvoorbeeld vlak 1001-2000 gebruikers). Dit is moontlik om op te gradeer na 'n hoër vlak, met 'n toeslag.
- As die aantal gelisensieerde gebruikers oorskry word, sal nuwe gebruikers geskep word sonder die reg om aan te meld ('JIRA-gebruikers' globale toestemming).
- Inproppe kan slegs vir dieselfde aantal gebruikers as die hoofsagteware gelisensieer word.
- Slegs produktiewe installasies word vereis om gelisensieer te wees, vir die res kan jy 'n ontwikkelaarlisensie kry: .
- Om onderhoud te koop, is die aankoop van Hernu Sagteware-onderhoud nodig - die koste is ongeveer 50% van die koste van die oorspronklike sagteware. Hierdie kenmerk is nie vir die datasentrum beskikbaar nie en is nie van toepassing op inproppe nie – jy sal die volle koste jaarliks moet betaal om dit te ondersteun.
Dus, jaarlikse sagteware-ondersteuning kos meer as 50% van die totale koste van die sagteware in die geval van die Server-uitgawe en 100% in die geval van die Data Center-uitgawe - dit is aansienlik meer as die meeste ander verskaffers. Na my mening is dit 'n beduidende nadeel van die Atlassian-sakemodel.
Kenmerke van die oorgang van die bedieneruitgawe na die datasentrum:
- Die oorgang van die Bediener-uitgawe na die Datasentrum is betaal. Prys kan hier gevind word .
- Wanneer jy van die Bediener-uitgawe na die Datasentrum oorskakel, hoef jy nie te betaal vir die verandering van die uitgawe van die inproppe nie – die inproppe vir die Bediener-uitgawe sal funksioneer. Maar dit sal nodig wees om lisensies vir inproppe vir die Data Center-uitgawe te hernu.
- Jy kan inproppe gebruik wat nie 'n weergawe het vir gebruik met Datasentrum-uitgawes nie. Terselfdertyd kan sulke inproppe natuurlik dalk nie reg werk nie en dit is beter om vooraf 'n alternatief vir sulke inproppe te verskaf.
- Opgradering na die Data Center-uitgawe word gedoen deur 'n nuwe lisensie te installeer. Terselfdertyd is die lisensie vir die Server-uitgawe steeds beskikbaar.
- Daar is geen funksionele verskille tussen die datasentrum- en bediener-uitgawes vir gebruikers nie, alle verskille is slegs in die funksies vir administrasie en die tegniese vermoëns van die installasie.
- Die koste van sagteware en inproppe verskil vir die bediener- en datasentrum-uitgawes. Die verskil in koste is dikwels minder as 5% (nie noodsaaklik nie). 'n Voorbeeld van kosteberekening word hieronder getoon.
Funksionele omvang van implementering
Die basis Atlassian-sagtewarepakket bevat 'n groot aantal kenmerke, maar dikwels ontbreek die kenmerke wat deur die stelsel verskaf word, ernstig. Soms is selfs die eenvoudigste funksies nie in die basiese pakket beskikbaar nie, so inproppe is onontbeerlik vir byna enige implementering. Vir die Jira-stelsel gebruik ons die volgende inproppe (die prentjie is klikbaar):
Vir die Confluence-stelsel gebruik ons die volgende inproppe (die prentjie is klikbaar):
Opmerkings oor tabelle met inproppe:
- Alle pryse is gebaseer op 2000 gebruikers;
- Pryse is gebaseer op die pryse wat aangedui word , die werklike koste (met afslag) is laer;
- Soos u kan sien, is die totale bedrag feitlik dieselfde vir die datasentrum- en bediener-uitgawes;
- Slegs inproppe met ondersteuning vir die Data Center-uitgawe is vir gebruik gekies. Ons het die res van die inproppe van die planne uitgesluit vir die stabiliteit van die stelsel.
Die funksionaliteit word kortliks in die Kommentaar-kolom beskryf. Bykomende inproppe het die funksionaliteit van die stelsel uitgebrei:
- Verskeie visuele gereedskap bygevoeg;
- Verbeterde integrasiemeganismes;
- Bygevoeg gereedskap vir waterval model projekte;
- Bygevoeg gereedskap vir skaalbare Scrum om die werk van groot projekspanne te organiseer;
- Bygevoeg funksionaliteit vir tyd dop;
- Bygevoeg gereedskap vir die outomatisering van bedrywighede en die opstel van die oplossing;
- Bygevoeg funksionaliteit om die administrasie van die oplossing te vereenvoudig en te outomatiseer.
Daarbenewens gebruik ons . Hierdie toepassing laat jou toe om lêers in eksterne toepassings (MS Office) te redigeer en dit terug te stuur na Confluence (inteken).
Aansoek vir gebruikerswerkstasies (dik kliënt) ALM Werk Jira Kliënt besluit om nie te gebruik nie weens swak verskafferondersteuning en negatiewe resensies.
Vir integrasie met MS Project ons gebruik 'n selfgeskrewe toepassing waarmee u kwessiestatusse in MS Project vanaf Jira en omgekeerd kan opdateer. In die toekoms, vir dieselfde doeleindes, beplan ons om 'n betaalde inprop te gebruik , wat as 'n byvoeging vir MS Project geïnstalleer is.
Integrasie met eksterne toepassings geïmplementeer deur toepassingskakels. Terselfdertyd is integrasies vir Atlassian-toepassings vooraf gekonfigureer en werk onmiddellik na opstelling, byvoorbeeld, jy kan inligting oor Kwessies in Jira op 'n bladsy in Confluence vertoon.
Die REST API word gebruik om toegang tot die Jira- en Confluence-bedieners te kry: .
Die SOAP en XML-RPC API's is opgeskort en nie beskikbaar in die nuwe weergawes vir gebruik nie.
Gevolgtrekking
Dus, ons het die tegniese kenmerke van die implementering van 'n stelsel wat op Atlassian-produkte gebaseer is, oorweeg. Die voorgestelde oplossing is een van die moontlike oplossings en is goed geskik vir 'n korporatiewe omgewing.
Die voorgestelde oplossing is skaalbaar, foutverdraagsaam, bevat drie omgewings vir die organisering van ontwikkeling en toetsing, bevat al die nodige elemente vir samewerking in die stelsel en bied 'n wye reeks projekbestuurnutsmiddels.
Ek sal graag vrae in die kommentaar beantwoord.
Bron: will.com