O Azure DevOps e o ServiceNow costumam ser mencionados nas mesmas conversas, e logo surge uma suposição comum: que um pode substituir o outro. Eles resolvem problemas diferentes e funcionam melhor quando usados em conjunto.
Veja a seguir o que cada um lida, onde há sobreposição entre os dois e como eles se complementam.
As diferenças entre Azure DevOps e ServiceNow
O Azure DevOps é uma plataforma de desenvolvimento de software. As equipes a utilizam para planejar, criar, testar e entregar código por meio de quadros, repositórios, pipelines, planos de teste e artefatos. Ela faz parte do dia a dia da equipe de engenharia, e seu trabalho abrange desde a primeira linha de um item do backlog até o momento em que uma versão é lançada.
O ServiceNow é uma plataforma de Gerenciamento de Serviços de TI. As equipes a utilizam para operar e dar suporte aos serviços depois que eles entram em operação: registrando incidentes, atendendo a solicitações, gerenciando mudanças e acompanhando ativos por meio de um banco de dados de gerenciamento de configuração. Está integrado às equipes de operações de TI e de serviços e abrange o ciclo de vida do serviço para todos que dependem deles.
| Azure DevOps | ServiceNow | |
| Para que serve | Construir e entregar software | Executar e dar suporte a serviços de TI |
| Usuários principais | Desenvolvedores, QA, engenheiros de DevOps | Suporte de TI, gerentes de serviço, IT Ops |
| Módulos principais | Boards, Repos, Pipelines, Test Plans, Artifacts | Incidente, Requisição, Mudança, Problema, CMDB |
| Etapa do trabalho | Antes e durante um lançamento | Depois que os serviços entram em operação |
| Unidade principal de trabalho | Item de trabalho (funcionalidade, bug, tarefa) | Chamado (incidente, requisição, mudança) |
Onde há sobreposição e onde não há
A sobreposição é limitada e ocorre principalmente no Gerenciamento de Mudanças. O DevOps Change Velocity do ServiceNow se conecta a pipelines de CI/CD, incluindo o Azure DevOps, para criar e aprovar solicitações de mudança automaticamente à medida que o código avança para a produção. Esse é o único ponto em que as duas plataformas se encontram por padrão.
Em todos os outros aspectos, elas seguem seus próprios caminhos. Controle de código-fonte, CI/CD e gerenciamento de testes pertencem ao Azure DevOps. O tratamento de incidentes, as solicitações de serviço, os SLAs, o rastreamento de ativos e o Gerenciamento de Conhecimento pertencem ao ITSM. As duas cobrem etapas consecutivas da mesma história: uma equipe desenvolve o software e outra mantém os serviços em funcionamento para as pessoas que os utilizam. Essa relação é a razão pela qual a integração entre ferramentas de desenvolvimento e de serviço é importante.
O Azure DevOps pode substituir um ITSM?
Não. O Azure DevOps acompanha o trabalho de desenvolvimento, não as operações de serviços de TI. Ele não possui catálogo de serviços, mecanismo de SLA, Gerenciamento de Incidentes ou Problemas, nem banco de dados de gerenciamento de configuração. Uma organização que encaminha todas as questões de TI por meio dos painéis do Azure DevOps perde a estrutura que um ITSM foi projetado para oferecer: solicitações categorizadas e priorizadas de acordo com os SLAs, autoatendimento para toda a força de trabalho, governança em todo o ambiente de TI e relatórios sobre o desempenho dos serviços.
A distinção é simples. O Azure DevOps desenvolve o software. Um ITSM mantém os serviços em funcionamento para todos que dependem deles. Cada um é essencial em sua etapa, e nenhum deles faz o trabalho do outro.
Como um ITSM como o InvGate Service Management se integra ao Azure DevOps
Quando uma central de atendimento e uma equipe de desenvolvimento compartilham informações, as questões são resolvidas mais rapidamente. O InvGate Service Management se conecta ao Azure DevOps para que ambas as equipes trabalhem a partir do mesmo contexto.
A integração vincula os itens de trabalho do Azure DevOps, os recursos, requisitos e bugs de código que os desenvolvedores acompanham, às solicitações do InvGate Service Management. Assim que um item de trabalho é vinculado, os agentes autorizados visualizam seu status, ID e título diretamente na solicitação da central de atendimento, de modo que um ticket relacionado a um bug em desenvolvimento já contém essas informações.
A configuração é feita em duas etapas: gere um token de acesso pessoal no Azure DevOps e, em seguida, configure a integração no InvGate Service Management. As permissões são configuráveis, de modo que você decide quais agentes, administradores e gerentes podem vincular itens de trabalho e visualizar seus detalhes. Os usuários do InvGate Service Management acessam as informações vinculadas sem precisar de uma licença própria do Azure DevOps.
O resultado é uma transferência tranquila entre o suporte e o desenvolvimento: visibilidade compartilhada, resolução mais rápida, menos mensagens para acompanhar o status e muito mais.
