Está a planear implementar software Atlassian (Jira, Confluence)? Non queres cometer crueis erros de deseño que terán que resolverse no último momento?
Entón, este é o lugar para ti: estamos considerando a implementación de Atlassian Jira + Confluence nas corporacións, tendo en conta varios aspectos técnicos.
Ola, son propietario do produto en RSHB e son responsable do desenvolvemento dun sistema de xestión do ciclo de vida (LCMS) construído nos produtos de software Atlassian Jira e Confluence.
Neste artigo vou describir os aspectos técnicos da construción dun sistema de xestión da vida. O artigo será útil para quen planea implementar ou estea a desenvolver Atlassian Jira e Confluence nun ambiente corporativo. O artigo non require coñecementos especiais e está destinado a un nivel inicial de familiaridade cos produtos Atlassian. O artigo será útil para administradores, propietarios de produtos, xestores de proxectos, arquitectos e calquera persoa que planea implementar sistemas baseados no software Atlassian.
Introdución
O artigo discutirá cuestións técnicas da implementación dun Sistema de Xestión do Ciclo de Vida (LCMS) nun ambiente corporativo. Imos primeiro definir o que isto significa.
Que significa unha solución corporativa?
Isto significa a solución:
- Escalable. Se a carga aumenta, técnicamente é posible aumentar a capacidade do sistema. Separan a escala horizontal e vertical: coa escala vertical, a potencia dos servidores aumenta, coa escala horizontal, o número de servidores para o sistema aumenta.
- Tolerante a fallos. O sistema permanecerá dispoñible se un elemento falla. En xeral, os sistemas corporativos non requiren tolerancia a fallos, pero só consideraremos esa solución. Pretendemos ter varios centos de usuarios competitivos no noso sistema e o tempo de inactividade será moi crítico.
- Soportado. A solución debe ser apoiada polo vendedor. O software non compatible debe substituírse por software propietario ou outro software compatible.
- Instalación Autoxestionado (On-premise). Autoxestionado é a posibilidade de instalar software non na nube, senón nos teus propios servidores. Para ser máis precisos, todas estas son opcións de instalación non SaaS. Neste artigo consideraremos as opcións de instalación só para autoxestionadas.
- Posibilidade de desenvolvemento e probas independentes. Para organizar cambios previsibles no sistema, requírese un sistema separado para o desenvolvemento (cambios no propio sistema), un sistema de probas (Staging) e un sistema produtivo para os usuarios.
- Outros. Admite varios escenarios de autenticación, admite rexistros de auditoría, ten un modelo de rol personalizable, etc.
Estes son os principais elementos das solucións empresariais e, por desgraza, adoitan esquecerse ao deseñar un sistema.
Que é un sistema de xestión do ciclo de vida (LCMS)?
En resumo, no noso caso trátase de Atlassian Jira e Atlassian Confluence, un sistema que proporciona ferramentas para organizar o traballo en equipo. O sistema non "impón" regras para organizar o traballo, pero ofrece unha variedade de ferramentas para o traballo, incluíndo Scrum, táboas Kanban, un modelo en cascada, Scrum escalable, etc.
O nome LMS non é un termo da industria nin un concepto de uso común, é simplemente o nome do sistema no noso Banco. Para nós, o LMS non é un sistema de seguimento de erros, nin un sistema de xestión de incidentes nin un sistema de xestión de cambios.
Que inclúe a implementación?
A implementación da solución consta de moitos problemas técnicos e organizativos:
- Asignación de capacidade técnica.
- Compra de software.
- Creación dun equipo para implementar a solución.
- Instalación e configuración da solución.
- Desenvolvemento da arquitectura de solucións. Modelo de conduta.
- Elaboración da documentación operativa, incluíndo instrucións, regulamentos, deseño técnico, regulamentos, etc.
- Cambio de procesos da empresa.
- Creación dun equipo de apoio. Desenvolvemento de SLA.
- Formación de usuarios.
- Outros.
Neste artigo analizaremos os aspectos técnicos da implantación, sen detalles sobre o compoñente organizativo.
Características de Atlassian
Atlassian é líder en moitos segmentos:
(O liderado débese á exitosa adquisición de AgileCraft coa súa solución na nube)
Os produtos Atlassian ofrecen todas as funcións empresariais que necesitas. Notarei as seguintes características:
- As solucións de Atlassian baséanse no servidor web Java Tomcat. O software Apache Tomcat inclúese co software Atlassian como parte da instalación; non pode cambiar a versión de Apache Tomcat instalada como parte do software Atlassian, aínda que a versión estea desactualizada e conteña vulnerabilidades. A única opción é esperar a unha actualización de Atlassian, cunha versión máis recente de Apache Tomcat. Agora, por exemplo, as versións actuais de Jira teñen Apache Tomcat 8.5.42 e Confluence ten Apache Tomcat 9.0.33.
- Interface fácil de usar, as mellores prácticas dispoñibles no mercado para esta clase de software están implementadas.
- Solución totalmente personalizable. Con modificacións, pode implementar calquera cambio na funcionalidade básica para o usuario.
- Ecosistema desenvolvido. Hai varios centos de socios: , incluíndo 16 socios en Rusia. É a través de socios en Rusia que podes mercar software, complementos de Atlassian e recibir formación. Son os socios os que desenvolven e admiten a maioría dos complementos.
- Tenda de aplicacións (complementos): . Os complementos amplían significativamente a funcionalidade do software Atlassian. A funcionalidade básica do software Atlassian é bastante modesta; para case calquera tarefa, faise necesario instalar complementos adicionais de balde ou por diñeiro adicional. Polo tanto, os custos do software poden resultar significativamente superiores ao estimado orixinalmente.
Actualmente, varios miles de complementos publicáronse na tenda, case un milleiro deles foron probados e validados baixo o programa de aplicacións aprobados por Data Center. Estes complementos poden considerarse estables e axeitados para o seu uso en sistemas ocupados.
Aconsélloche que abordes coidadosamente o problema da planificación de complementos, isto afecta moito ao custo da solución, moitos dos complementos poden levar á inestabilidade do sistema e o fabricante do complemento non ofrece soporte para resolver o problema. - Formación e certificacións:
- Admítense os mecanismos SSO e SAML 2.0.
- O soporte para escalabilidade e tolerancia a fallos só está dispoñible nas edicións de Data Center. Esta edición apareceu por primeira vez en 2014 (Jira 6.3). A funcionalidade das edicións de Data Center está a ser constantemente ampliada e mellorada (por exemplo, a posibilidade de instalar un só nodo apareceu só en 2020). O enfoque dos complementos para as edicións de Data Center cambiou moito en 2018 coa introdución de aplicacións aprobadas por Data Center.
- Custo do apoio. O custo do soporte do provedor é case igual ao custo total das licenzas de software. A continuación ofrécese un exemplo de cálculo do custo das licenzas.
- Falta de lanzamentos a longo prazo. Hai os chamados , pero, como todas as outras versións, son compatibles durante 2 anos. Coa diferenza de que para as versións Enterprise só se lanzan correccións, sen engadir novas funcionalidades.
- Opcións de soporte ampliadas (con custo adicional).
- Admítense varias opcións de DBMS. O software Atlassian inclúe un DBMS H2 gratuíto; este DBMS non se recomenda para uso produtivo. Os seguintes DBMS son compatibles para uso produtivo: Amazon Aurora (só centro de datos) PostgreSQL, Azure SQL, MySQL, Oracle DB, PostgreSQL, MS SQL Server. Hai restricións nas versións compatibles e moitas veces só se admiten versións antigas, pero para cada DBMS hai unha versión con soporte de provedores:
,
.
Arquitectura técnica
Explicacións para o diagrama:
- O diagrama mostra a implantación no noso Banco; esta configuración dáse como exemplo e non se recomenda.
- nginx ofrece funcionalidade de proxy inverso para Jira e Confluence.
- A tolerancia a fallos do DBMS implétase mediante o DBMS.
- Os cambios transfírense entre ambientes mediante o complemento Configuration Manager for Jira.
- AppSrv no diagrama é un servidor de aplicacións propietario para informes e non usa software Atlassian.
- A base de datos EasyBI creouse para construír cubos e informar mediante o complemento eazyBI Reports and Charts for Jira.
- O servizo Confluence Synchrony (un compoñente que permite a edición simultánea de documentos) non está separado nunha instalación separada e lánzase xunto con Confluence, no mesmo servidor.
Licenzas
As cuestións de licenzas de Atlassian merecen un artigo aparte; aquí só mencionarei principios xerais.
Os principais problemas que atopamos foron problemas de licenza para as edicións de Data Center. Funcións de licenza para as edicións de servidor e centro de datos:
- A licenza para a edición do servidor é perpetua e o comprador pode usar o software mesmo despois de que caduque a licenza. Pero despois de caducar a licenza, o comprador queda privado do dereito a recibir soporte para o produto e actualizar o software ás últimas versións.
- A licenza baséase no número de usuarios no sistema de permisos globais "Usuarios JIRA". Non importa se usan o sistema ou non; aínda que os usuarios nunca iniciaran sesión no sistema, todos os usuarios serán tidos en conta para a licenza. Se se supera o número de usuarios con licenza, a solución sería eliminar o permiso "Usuarios JIRA" dalgúns usuarios.
- Unha licenza de Data Center é efectivamente unha subscrición. Requírese unha taxa anual de licenza. Se o prazo vence, bloquearase o traballo co sistema.
- Os prezos das licenzas poden cambiar co paso do tempo. Como mostra a práctica, en maior medida e, quizais, significativamente. Polo tanto, se as súas licenzas custan a mesma cantidade este ano, entón o próximo ano o custo das licenzas pode aumentar.
- A licenza realízase por usuario por nivel (por exemplo, usuarios de nivel 1001-2000). É posible actualizar a un nivel superior, cun pago adicional.
- Se se supera o número de usuarios con licenza, crearanse novos usuarios sen dereito a iniciar sesión (permiso global 'Usuarios JIRA').
- Os complementos só poden ter licenza para o mesmo número de usuarios que o software principal.
- Só as instalacións produtivas precisan ter licenza; para o resto podes obter unha licenza de programador: .
- Para adquirir o mantemento, cómpre mercar o mantemento de Renew Software; o custo é de aproximadamente o 50 % do custo do software orixinal. Esta función non está dispoñible para Data Center e non se aplica aos complementos; para admitilos, terás que pagar o prezo total anualmente.
Así, o soporte anual de software custa máis do 50% do custo total do software no caso da edición Server e do 100% no caso da edición Data Center, é moito máis que a maioría dos outros provedores. Na miña opinión, esta é unha desvantaxe significativa do modelo de negocio de Atlassian.
Características da transición da edición Server ao Data Center:
- Hai unha taxa por actualizar da edición Server a Data Center. O custo pódese consultar aquí .
- Ao cambiar da edición do servidor ao centro de datos, non é necesario pagar por cambiar a edición dos complementos; os complementos para a edición do servidor seguirán funcionando. Pero será necesario renovar as licenzas dos complementos para a edición Data Center.
- Podes usar complementos que non teñan unha versión para usar coas edicións de Data Center. Non obstante, por suposto, tales complementos poden non funcionar correctamente e é mellor proporcionar unha alternativa a estes complementos con antelación.
- A transición á edición Data Center realízase instalando unha nova licenza. Non obstante, a licenza para a edición do servidor aínda segue dispoñible.
- Non hai diferenzas funcionais entre as edicións Data Center e Server para os usuarios; todas as diferenzas están só nas funcións administrativas e nas capacidades de instalación técnica.
- O custo do software e dos complementos varía para as edicións Server e Data Center. A diferenza de custo adoita ser inferior ao 5% (non significativo). A continuación dáse un exemplo de cálculo de custos.
Ámbito funcional de implantación
O paquete básico de software Atlassian inclúe unha gran cantidade de capacidades, pero moitas veces as capacidades proporcionadas polo sistema carecen moito. Ás veces, incluso as funcións máis sinxelas non están dispoñibles no paquete básico, polo que os complementos son indispensables para case calquera implementación. Para o sistema Jira usamos os seguintes complementos (na imaxe se pode facer clic):
Para o sistema Confluence usamos os seguintes complementos (na imaxe se pode facer clic):
Comentarios sobre táboas con complementos:
- Todos os prezos están baseados en 2000 usuarios;
- Os prezos mostrados baséanse nos prezos indicados , o custo real (con descontos) é menor;
- Como vedes, o importe total é practicamente o mesmo para as edicións Data Center e Server;
- Só se seleccionan os complementos que admiten a edición Data Center. Excluímos os complementos restantes dos plans de estabilidade do sistema.
A funcionalidade descríbese brevemente na columna Comentario. Os complementos adicionais ampliaron a funcionalidade do sistema:
- Engadiuse varias ferramentas visuais;
- Melloráronse os mecanismos de integración;
- Ferramentas engadidas para proxectos de modelos de fervenza;
- Ferramentas engadidas para Scrum escalable, para organizar o traballo de grandes equipos de proxectos;
- Funcionalidade engadida para o seguimento do tempo;
- Ferramentas engadidas para automatizar operacións e configurar a solución;
- Funcionalidade engadida para simplificar e automatizar a administración da solución.
Ademais usamos . Esta aplicación permítelle editar ficheiros en aplicacións externas (MS Office) e devolvelos a Confluence (check-in).
Aplicación para estacións de traballo de usuarios (cliente grueso) Cliente Jira de ALM Works decidiu non usalo debido á mala asistencia dos provedores e ás críticas negativas.
Para integración con MS Project Usamos unha aplicación autoescrita que che permite actualizar os estados dos problemas en MS Project desde Jira e viceversa. No futuro, para os mesmos fins, pensamos utilizar un complemento de pago , que se instala como complemento para MS Project.
Integración con aplicacións externas implementado a través de ligazóns de aplicación. Ao mesmo tempo, para as aplicacións Atlassian, as integracións están preconfiguradas e funcionan inmediatamente despois da configuración; por exemplo, pode mostrar información sobre problemas en Jira nunha páxina de Confluence.
Para acceder aos servidores Jira e Confluence, utilízase a API REST: .
A API SOAP e XML-RPC están en desuso e non están dispoñibles para o seu uso en versións máis recentes.
Conclusión
Entón, analizamos as características técnicas da implementación dun sistema baseado en produtos Atlassian. A solución proposta representa unha solución posible e é moi adecuada para un entorno empresarial
A solución proposta é escalable, tolerante a fallos, contén tres contornos para organizar o desenvolvemento e as probas, contén todos os elementos necesarios para a colaboración no sistema e ofrece unha ampla gama de ferramentas para a xestión de proxectos.
Estarei encantado de responder ás preguntas nos comentarios.
Fonte: www.habr.com