O seu portal interno do desenvolvedor pode ser mantido?

Os portais internos para desenvolvedores são relativamente novos. Tal como acontece com todas as coisas novas, existem múltiplas teorias sobre o que exatamente deve ser realizado com elas. Há uma coisa com a qual todos concordam: portais e plataformas internas para desenvolvedores são uma interface central para desenvolvedores e precisam ser fáceis de manter e evoluir. Afinal, se as pessoas, os processos e a tecnologia evoluem, também evoluem as interfaces que atendem aos desenvolvedores.

Como você pode saber se a sua escolha de portal pode evoluir e ser sustentável? Vamos explorar tudo sobre isso.

Um portal interno eficaz para desenvolvedores é composto por vários elementos: catálogo de software, autoatendimento do desenvolvedor, scorecards, automações e visualizações. Embora todos façam parte da entrega de experiências ao desenvolvedor, examinaremos dois:

• O catálogo de software (catálogo de serviços)
• Ações de autoatendimento

Catálogos de software precisam de um modelo de dados flexível

Um modelo de dados flexível significa ser capaz de modelar seu DNA de engenharia e casos de uso no portal, tanto para:

• Reflita o ciclo de vida real de entrega de software (SDLC) e a pilha de tecnologia no portal, o que tornará o portal confiável tanto para desenvolvedores quanto para gerentes.
• Adicione casos de uso ao portal, como adicionar dados AppSec para dar suporte à conformidade padrão AppSec no portal.

Um bom portal permite definir, alterar ou adicionar tipos de entidades no catálogo do software, bem como os diferentes relacionamentos entre esses tipos de entidades.

Vejamos ambos com mais detalhes.

Tipos de entidades personalizadas

Os tipos de entidade são recursos, componentes e APIs. A entidade forma o que chamamos de modelo de dados do catálogo de software. Este é o mapa que o catálogo de software usa para explicar o mundo SDLC aos seus usuários. O que fica de fora do mapa não existe no portal.

Aqui estão alguns exemplos de entidades que você pode querer incluir em seu portal:

• Permissões na nuvem para que você possa fornecer acesso just-in-time e trabalhar com mais segurança.
• Alertas para que você possa unificar alertas no portal do desenvolvedor e tornar mais fácil para os desenvolvedores entenderem e resolverem problemas.
• Incidentes para que você possa oferecer suporte de plantão e tornar a experiência melhor para os desenvolvedores e reduzir o tempo médio de reparo (MTTR).
• Vulnerabilidades para que você possa incluir segurança em todas as rotinas do desenvolvedor.
• CI/CD para que você possa usar o portal como um catálogo de CI/CD.
• Dados de API para que você possa usar o portal para governança de API e muito mais.

Ser capaz de incluir essas entidades sem codificação significativa é fundamental.

O que procurar: portais que possuem um número fixo de tipos de entidades (por exemplo, apenas o modelo C4) ou que necessitam de codificação para alterá-los.

Compreendendo as dependências

Em vez de presumir que existem relacionamentos fixos entre entidades, você precisa distinguir entre diferentes tipos de dependências, como separar recursos de nuvem de tempo de execução (instâncias de computação) de recursos de armazenamento (bancos de dados e buckets AWS S3).
Você também deseja que seu portal seja capaz de especificar relacionamentos múltiplos e distintos entre entidades, proporcionando granularidade e clareza na compreensão das dependências de recursos.

O que procurar: um portal onde você não pode controlar os relacionamentos entre tipos de entidades

Falta de contexto e confiança = falta de adoção

Sem a capacidade de usar tipos de entidade personalizados ou distinguir dependências, seu catálogo de software não representa os principais aspectos do SDLC. Como resultado, oferece menos contexto e utilidade para as partes interessadas. Isto é crucial porque os desenvolvedores estão menos inclinados a adotar totalmente um portal que não atende a muitas das suas necessidades.

Ingestão de dados automatizada e em tempo real

Os portais internos para desenvolvedores e, especificamente, o catálogo de software neles contidos, precisam permanecer atualizados. Para ser sustentável e confiável, isso precisa acontecer automaticamente. Ao usar a descoberta automática, atualizações de dados em tempo real e diversas formas de inserir dados, você pode evitar a demorada tarefa de manutenção manual, garantindo que as informações do seu portal estejam sempre atualizadas e precisas.

Aqui estão os requisitos básicos:

• Descoberta automática: O catálogo deve localizar automaticamente as entidades de software relevantes em toda a organização. Isto envolve a varredura de vários sistemas e plataformas para identificar e catalogar entidades novas ou atualizadas sem a necessidade de entrada manual. Sem a descoberta automática, você dependerá do trabalho do desenvolvedor e isso não é um bom começo.
• Reconciliação e atualizações em tempo real: O catálogo deve atualizar regularmente seus dados para corresponder às “fontes da verdade”, como sistemas de terceiros, para garantir sua precisão. Isto é importante para manter a confiança no portal e aplica-se a todos os tipos de dados, incluindo custos, permissões, alertas e vulnerabilidades. O sistema deve corrigir quaisquer discrepâncias entre as informações catalogadas e o estado real dos recursos. Um excelente exemplo são as vulnerabilidades de segurança. Os dados de vulnerabilidade do AppSec no catálogo devem permanecer atualizados. Se estiver desatualizado, a confiança no catálogo diminui e perde a sua eficácia em solicitar ações oportunas. Consequentemente, isto prejudica o papel do portal como fonte confiável de alertas.
• Múltiplos caminhos de ingestão: A entrada eficiente de dados deve ser automatizada, evitando a entrada manual sempre que possível. As atualizações manuais estão sujeitas a erros e representam uma carga desnecessária para os desenvolvedores. As opções automatizadas incluem:
  • API REST: Permitir que sistemas automatizados e scripts atualizem diretamente o catálogo.
  • IaC (Infraestrutura como Código): Integração com ferramentas IaC para atualizar automaticamente o catálogo durante os processos de implantação.
  • Webhooks: Usar webhooks de várias plataformas para receber atualizações sobre alterações de recursos ou configurações.

Esses recursos são vitais para manter um catálogo preciso e atualizado em um ambiente dinâmico e de grande escala, ajudando a agilizar as operações e melhorar a eficiência. Sem esses recursos, o esforço manual necessário para manter o catálogo torna-se impraticável e sujeito a erros, o que pode desacelerar significativamente a organização. Além disso, exigir que os desenvolvedores atualizem manualmente o catálogo sem oferecer benefícios claros pode dificultar o uso do portal.

O que procurar: Portais que exigem que os desenvolvedores realizem muito trabalho manual com YAMLs. Isso não é apenas inconveniente, mas pode criar sérios problemas de manutenção e exigir muitos desenvolvedores, sem lhes dar nada em troca.

Plugins não conseguem consertar um modelo de dados inflexível

Há uma tendência de querer resolver os problemas que acabamos de descrever com plugins. Não é possível representar tipos adicionais de entidades (“tipos”) no catálogo de software devido a um modelo de dados inflexível? Não tem problema, vamos usar um plugin.

No entanto, às vezes, os plug-ins podem agravar o problema por não terem a funcionalidade e a flexibilidade que você espera, prejudicando, em última análise, a eficácia do portal interno do desenvolvedor.

Por que isso é um problema?

O objetivo de um portal para desenvolvedores é fornecer aos desenvolvedores informações relevantes e abstratas, adaptadas às suas necessidades específicas. Para conseguir isso, são necessários dois elementos principais:

• Armazenamento central de metadados: O catálogo de software deve usar um repositório central de metadados onde todos os dados — do modelo principal ou de ferramentas de terceiros — possam ser pesquisados ​​contextualmente e usados ​​para criar visualizações abrangentes de informações, como scorecards de padrões e muito mais. Em alguns portais, os dados do plugin não ficam junto com os dados do catálogo principal do software. Sem essa centralização, os dados do plugin não podem ser pesquisados ​​de forma eficaz, dificultando a resposta a questões importantes como: “Quais serviços têm incidentes abertos?” Essa limitação reduz significativamente a utilidade do catálogo de software para qualquer caso de uso do portal interno do desenvolvedor. Esteja você procurando problemas de custos ou determinando quais serviços não estão prontos para produção, você não pode pesquisar esses problemas com eficiência, microsserviço por microsserviço.
• Ser capaz de abstrair dados ao seu gosto: A ligação entre os dados provenientes de sistemas de terceiros e a interface do usuário que exibe esses dados é restrita. Pode ser extremamente difícil mostrar mais ou menos detalhes ou exibir os dados de maneira diferente. Freqüentemente, as mudanças exigem a bifurcação de um plug-in, o que significa que são necessárias habilidades de desenvolvimento em React, e elas não são comumente encontradas entre os engenheiros de DevOps. Após a bifurcação, a manutenção é de sua responsabilidade isolada (e da sua organização).

Muitas ações de autoatendimento (incluindo operações do dia 2)

Você deseja que seu portal seja capaz de fornecer autoatendimento diretamente para uma ampla gama de ações, como: implantação de serviços, reversão, acionamento de incidentes, criação de recursos de nuvem, alternância de sinalizadores de recursos, adição de segredos, obtenção de permissões temporárias de banco de dados e configuração de desenvolvimento ambientes.

Isso significa que os desenvolvedores podem fazer mais do que criar novos serviços, mas também usar ações de autoatendimento para operações do Dia 2.

Pipelines de CI/CD existentes, como GitHub Workflows, GitLab CI, Argo Workflows, operadores AWS Lambda e Kubernetes vêm com ações poderosas e prontas para uso que permitem a execução rápida e confiável de várias tarefas.

Por exemplo, GitHub Workflows fornece centenas de ações integradas disponíveis em seu mercado, que podem ser usadas para gerenciar com eficiência uma ampla gama de operações. Mesmo para scaffolding, a biblioteca Cookiecutter pode ser incorporada em pipelines de CI/CD para personalizar e criar repositórios de acordo com padrões especificados com maior facilidade e flexibilidade.

Dadas essas capacidades, um portal interno para desenvolvedores deve se concentrar no aprimoramento da camada de UI dos formulários de ação de autoatendimento e no fortalecimento da integração com esses mecanismos de CI/CD existentes. Essa abordagem garante uma experiência perfeita para os desenvolvedores, aproveitando os pontos fortes das ferramentas estabelecidas e, ao mesmo tempo, fornecendo uma interface amigável.

O que procurar: portais que possuem apenas uma maneira de acionar ações de autoatendimento, forçando você a copiar e substituir seu trabalho anterior, e que não possuem uma forte integração com seus pipelines de CI/CD atuais.

Principais conclusões

Um portal interno eficaz para desenvolvedores depende da integração de um catálogo de software robusto e de ações abrangentes de autoatendimento. Um modelo de dados flexível que suporte tipos de entidade personalizados e represente dependências com precisão é essencial para a criação de um catálogo útil e dinâmico.

A ingestão de dados automatizada e em tempo real garante que as informações permaneçam atuais, confiáveis ​​e livres dos encargos da manutenção manual. Esses recursos permitem coletivamente que os desenvolvedores encontrem e usem com eficiência os recursos de que precisam, promovendo um ambiente de desenvolvimento mais produtivo e simplificado.

Além disso, embora os plug-ins possam oferecer soluções rápidas, muitas vezes ficam aquém da flexibilidade e da funcionalidade, prejudicando potencialmente a eficácia geral do portal. Em vez disso, focar no aprimoramento da camada de UI dos formulários de ação de autoatendimento e no fortalecimento da integração com pipelines de CI/CD existentes garante uma experiência contínua e eficiente para os desenvolvedores.

Ao aproveitar os pontos fortes das ferramentas estabelecidas e fornecer uma interface fácil de usar, as organizações podem construir um portal para desenvolvedores que não apenas atenda às necessidades atuais, mas também se adapte e seja dimensionado à medida que essas necessidades evoluem, gerando, em última análise, maior adoção e satisfação entre os desenvolvedores.

Saiba mais sobre portais internos para desenvolvedores no Portal Talks de 26 a 27 de junho, que Jennifer Riggins do The New Stack apresentará.

A postagem Seu portal interno do desenvolvedor é sustentável? apareceu primeiro em The New Stack.