Projetar uma base de autoatendimento para desenvolvedores
Depois de ter uma boa compreensão do destino para seus sistemas de engenharia, você pode criar experiências de autoatendimento de desenvolvedor mais sofisticadas. Uma experiência de autoatendimento do desenvolvedor é criada com base em conceitos, padrões e componentes.
Embora você possa não precisar de tudo descrito aqui em sua organização hoje, você deve manter esses conceitos em mente se criar algo personalizado ou avaliar produtos relacionados. Seu modelo de experiência de autoatendimento para desenvolvedores pode ser composto por uma combinação de produtos internos, prontos para uso e de software livre. Produtos ou kits de ferramentas de portal de software livre, como Backstage.io , podem usar termos diferentes para alguns elementos do modelo descrito abaixo, mas o modelo ainda pode ajudar a orientá-lo.
Automatize fluxos de trabalho, agregue dados, comece de forma simples e expanda gradualmente
Seu objetivo é habilitar o autoatendimento com proteções por meio de execução e provisionamento de tarefas controladas e controladas, juntamente com visibilidade centralizada. As áreas mais valiosas para se concentrar são aquelas que são tediosas ou são coisas que o desenvolvedor não pode fazer sozinho devido à complexidade ou permissões. Esta última parte é importante para permitir que você siga o princípio do menor privilégio sem forçar os desenvolvedores a passar por um processo manual de service desk.
Embora você possa optar por estender seu pacote de DevOps para atender a essas necessidades, provavelmente precisará oferecer suporte a várias plataformas de aplicativos ao longo do tempo, e as ferramentas e processos específicos que dão suporte a elas também precisarão ser alterados. A questão central é que seus padrões são um alvo em movimento. Como afirmou um profissional de engenharia de plataforma:
As dificuldades envolvem a padronização ... e lidar com 'abandonware'... A padronização geralmente não é alcançada devido à possível interrupção de processos automatizados e à tarefa demorada de identificar as mudanças necessárias. - Martin, engenheiro de DevOps, grande empresa de logística
Mudar rapidamente para um padrão novo ou atualizado normalmente não é viável, e abandonar os processos existentes cria riscos. Sua organização pode já estar usando vários pacotes de DevOps ou diferentes combinações de ferramentas individuais e serviços de desenvolvedor por cenário. Mesmo com uma equipe central e uma solução padrão, à medida que suas necessidades de autoatendimento aumentam, a variabilidade é inevitável. Portanto, você desejará habilitar a experimentação controlada em que as equipes designadas podem experimentar novas tecnologias, estratégias de implantação e assim por diante, seguidas pela adoção deliberada e uma distribuição incremental.
Geralmente, as experiências de autoatendimento se enquadram em duas categorias principais: automação e agregação de dados.
Embora a agregação de dados crie boas experiências do usuário, a automação é mais importante:
A automação é fundamental e será amada por todos. A agregação [de dados] é secundária. – Peter, líder de engenharia de plataforma, empresa multinacional de tecnologia
Em sua jornada de engenharia de plataforma, você identificou problemas potencialmente resolvidos pela automação. Além de reduzir a carga cognitiva e o trabalho do desenvolvedor, a automação também pode ajudar a garantir que os aplicativos estejam conectados às melhores ferramentas e serviços para operações, segurança e outras funções para fazer seu trabalho.
No entanto, se você estiver trabalhando com mais de um sistema para impulsionar sua automação, algum nível de agregação de dados será útil para ajudar a rastrear solicitações automatizadas e os resultados associados. Você pode começar vinculando-se a sistemas externos para atender a outras necessidades ou para detalhar detalhes. A agregação e a visibilidade de dados também são importantes para auditoria, governança e redução de desperdícios (exemplo: ambientes não utilizados).
A automação de coisas como o provisionamento de infraestrutura pode ser feita usando integrações de sistema, mas você também pode acionar e facilitar um processo de fluxo de trabalho manual que parece automatizado para o desenvolvedor. Isso é útil nos estágios iniciais de sua plataforma, para novos produtos que você está trazendo para seu ecossistema ou em áreas que você não automatizou ou não pode automatizar usando um sistema (por exemplo, atribuição de licença de software). Com o design certo, você pode começar com um processo manual facilitado por algo como o Power Automate, que você alterna para um fluxo totalmente automatizado ao longo do tempo. Então, projete uma automação desde o início.
Comece de forma simples reutilizando investimentos existentes, como seus sistemas de engenharia ou um portal interno, criando CLIs, páginas da Web básicas ou até mesmo painéis do Power Pages, Power BI ou Microsoft Fabric e expandindo conforme a necessidade. Ter uma API consistente que o UX usa pode ajudá-lo a oferecer suporte a várias interfaces ao longo do tempo, à medida que suas necessidades e preferências mudam.
Componentes da plataforma de autoatendimento do desenvolvedor: API, gráfico, orquestrador, provedores e metadados
Considere os fundamentos do autoatendimento do desenvolvedor:
Como mostra a ilustração, os seguintes componentes compõem o núcleo do conceito de uma base de autoatendimento para desenvolvedores:
| Componente | Descrição |
|---|---|
| API da plataforma do desenvolvedor | Este é o seu único ponto de contato para experiências do usuário. É efetivamente o contrato do sistema com outros sistemas. |
| Gráfico da plataforma do desenvolvedor | Um gráfico de dados gerenciado e seguro que permite descobrir, associar e usar diferentes tipos de entidades e modelos. Uma entidade é um objeto que permite a agregação de dados de várias fontes, enquanto os modelos orientam as entradas do usuário que permitem a automação. |
| Orquestrador de plataforma de desenvolvedor | Um recurso que roteia e rastreia solicitações baseadas em modelo para executar ações em um sistema ou por meio de um processo manual. Essas solicitações são roteadas para um conjunto de provedores de plataforma de desenvolvedor que podem se integrar a qualquer número de sistemas de fluxo de trabalho diferentes ou outros serviços. |
| Provedores de plataforma de desenvolvedor | Um conjunto de componentes que encapsulam a lógica necessária para integração com sistemas downstream para dar suporte a operações CRUD em entidades e/ou atendimento de solicitações de ação baseadas em modelo. Cada provedor pode dar suporte a seu próprio tipo específico de modelos e emitir tipos exclusivos ou comuns de entidades. |
| Perfil do usuário e metadados da equipe | Uma capacidade de persistir informações sobre um conjunto de indivíduos vinculados a uma equipe conceitual para agrupamento e acesso à API da plataforma do desenvolvedor. O usuário está intimamente associado a uma conta de provedor de identidade (por exemplo, entrada da ID do Microsoft Entra), mas ele e uma equipe podem se vincular a qualquer número de representações do sistema downstream relacionadas. Uma implementação desse armazenamento de informações é reutilizar o gráfico da plataforma do desenvolvedor. A base de autoatendimento do desenvolvedor pode estabelecer um tipo de entidade comum para um usuário e uma equipe e manter essas informações no grafo. No entanto, manteremos esta loja separada por uma questão de clareza aqui. |
Esses componentes fundamentais permitem que você use e troque diferentes blocos de construção ao longo do tempo.
Eu tenho que construir tudo isso para começar?
Não. Primeiro, este é um modelo conceitual para ajudá-lo a pensar sobre o que uma fundação como essa deve ser capaz de fazer depois de concluída. Em segundo lugar, as especificidades da implementação são menos importantes aqui, pois a API da plataforma do desenvolvedor se torna sua interface principal. Sua implementação inicial pode começar usando interfaces e classes em seu código para as diferentes camadas descritas ou misturar outros produtos. Você também pode omitir aspectos porque o desenvolvimento do cliente diz que é simplesmente uma prioridade mais baixa. Comece com o que você tem e cresça.
API da plataforma do desenvolvedor
Você deve definir uma API de plataforma de desenvolvedor para atuar como o contrato do seu sistema. A API é usada por diferentes interfaces de usuário para permitir o acesso a dados ou o provisionamento de unidades e outras ações.
Essa API atua como uma importante camada de autenticação e segurança, limitando o acesso a APIs subjacentes brutas em outros sistemas a dados e operações mais específicos e controlados. A API fornece acesso à sua própria representação de um perfil de usuário, à função de alto nível de um usuário na plataforma (membro da equipe, administrador etc.) e aos identificadores do sistema do provedor de identidade principal. Para obter mais informações, consulte Usuários e equipes.
Provedores de plataforma de desenvolvedor
Dada a amplitude de uma plataforma de desenvolvedor interna, crie ou identifique sistemas que sigam um modelo de provedor extensível para introduzir funcionalidade na API. A ideia é que as principais funcionalidades, como automação e agregação de dados, sejam fornecidas pela interação com componentes conectáveis com interfaces bem definidas. Esse acoplamento flexível ajuda a conectar o que você precisa de forma incremental e melhora a capacidade de manutenção, pois você pode testar a funcionalidade independentemente do restante da fundação.
Também é uma maneira importante de permitir uma mentalidade de fonte interna escalável para sua plataforma. Normalmente, os esforços de sourcing interno em torno da engenharia da plataforma não ganham força devido a desafios com a manutenção contínua. Outras equipes podem estar dispostas a contribuir com a funcionalidade, mas são menos propensas a manter e testar algo dentro do núcleo de sua plataforma. Por outro lado, qualquer equipe centralizada tem capacidade limitada para manter o código contribuído ou até mesmo revisar solicitações pull. O conceito de um provedor de plataforma de desenvolvedor alivia essa tensão, permitindo que o código escrito de forma independente "se conecte" à funcionalidade principal dentro de sua base de autoatendimento para desenvolvedores. Embora você deva gerenciar cuidadosamente quais provedores você usa, revisar qualquer código de provedor e limitar a área de superfície que um determinado provedor pode acessar em sua plataforma de desenvolvedor, uma abordagem conectável pode ajudá-lo a fazer mais dimensionando o esforço em uma parte mais ampla da organização.
Principais conceitos do provedor de plataforma de desenvolvedor
Entities
O conceito de uma entidade é algo que um desenvolvedor ou outro sistema em sua plataforma de desenvolvedor interna precisa rastrear, atualizar, apresentar ou agir. As entidades podem ter relacionamentos entre si que, quando tomados em conjunto, compõem um gráfico que fornece informações críticas sobre partes de sua plataforma de desenvolvedor interna. Os provedores de plataforma de desenvolvedor podem gerar entidades para habilitar os principais recursos, incluindo:
- Exibindo recursos/ambientes provisionados externamente ou APIs disponíveis para descoberta e uso
- Expondo relacionamentos para análise de dependência, análise de impacto, descoberta, etc.
- Exibindo informações de mantenedor/propriedade para descoberta e colaboração
- Exibindo mais dados para uso em experiências do usuário
Encapsular essa funcionalidade em uma interface de provedor de plataforma de desenvolvedor bem definida simplifica a integração e o teste, permite a implantação independente e permite que desenvolvedores fora da equipe interna principal da plataforma de desenvolvedor contribuam e gerenciem provedores. Isso é importante em organizações grandes ou divisionais, onde nem todas as ferramentas, serviços ou plataformas são gerenciados centralmente, mas a organização mais ampla ainda deseja compartilhar recursos. Portanto, mesmo que você não siga esse caminho inicialmente, é algo para se pensar a longo prazo.
Propriedades comuns
Cada entidade deve ter um conjunto de propriedades comuns para permitir que a Fundação as gerencie. Algumas propriedades a serem consideradas incluem:
- Identificador exclusivo
- Nome
- Provedor de origem
- Associações opcionais para:
- Usuário proprietário
- Equipe proprietária
- Outras entidades
As propriedades do usuário e da equipe são importantes por três motivos: RBAC (controle de acesso baseado em função), descoberta e agregação de dados (como resumos no nível da equipe). Criar o RBAC desde o início é fundamental para a segurança e o crescimento de sua plataforma interna de desenvolvedor ao longo do tempo. Dado que o desenvolvimento é um esporte de equipe, descobrir com quem falar sobre uma entidade rapidamente se tornará fundamental para reutilização, suporte e innersourcing.
Entidades comuns e específicas do provedor
Você também deve ser capaz de estabelecer um conjunto de entidades normalizadas comuns de alto nível que vários provedores podem gerar. Por exemplo:
- Ambientes
- Recursos
- APIs
- Repositórios
- Componentes
- Ferramentas
Eles geralmente devem estar em um nível alto, como você colocaria no contexto do modelo C4 ou, no máximo, em diagramas de componentes de alto nível. Por exemplo, para um ambiente, você não precisa incluir os detalhes da topografia da infraestrutura interna: você só precisa de informações suficientes para listar e associar diferentes ambientes conceituais de vários provedores na mesma experiência do usuário. A entidade pode apontar para níveis mais baixos de detalhes fora do sistema, em vez de tentar consumir tudo. Eles fornecem pontos de partida para a descoberta que são fundamentais para permitir a agregação de dados ao longo do tempo.
Outros serão específicos para um caso de uso ou provedor específico, portanto, você deve pensar em como pode acomodar um conjunto crescente de tipos de entidade ao longo do tempo.
Modelos
O conceito de um modelo nesse contexto difere da ideia de entidades, pois elas se destinam a conduzir uma ação. Os cenários de exemplo incluem provisionamento de infraestrutura, criação de um repositório e outros processos de execução longa. Esses modelos também devem estar disponíveis por meio de provedores de plataforma de desenvolvedor extensível e devem dar suporte às mesmas propriedades comuns que as entidades, incluindo associações de entidades.
No entanto, eles também podem definir as entradas necessárias, especificadas pelo sistema ou pelo usuário, que são necessárias para executar a ação. Isso pode variar de qualquer coisa, como nomear o recurso, a adições opcionais.
Exemplos de modelos incluem:
- Modelos de infraestrutura como código (IaC)
- Modelos de aplicativo (iniciar à direita) ou repositórios de modelos
- Criar modelos de pipeline/fluxo de trabalho
- Pipeline de implantação/modelos de fluxo de trabalho
- Scripts parametrizados
- Fluxos parametrizados do Power Automate (exemplo: um fluxo de nuvem disparado por solicitação HTTP)
- Modelos de email
Assim como as entidades, os modelos podem incluir propriedades específicas do provedor.
Cada modelo pode ter uma representação diferente que é exclusiva para o provedor. Eles podem variar de modelos Terraform ou ARM a Helm Charts, fluxos de trabalho parametrizados do GitHub Actions ou Azure Pipelines, scripts simples ou formatos personalizados.
Os detalhes reais do modelo subjacente não precisam necessariamente ser armazenados centralmente. Eles podem existir em diferentes repositórios, registros ou catálogos. Por exemplo, você pode usar repositórios de modelos do GitHub para seus modelos de aplicativo, enquanto seus modelos de IaC podem existir em um repositório de catálogo restrito que os desenvolvedores só podem acessar indiretamente por meio de algo como Ambientes de Implantação do Azure. Outros modelos de IaC podem ser armazenados em um Registro de Artefatos do OCI, como gráficos do Helm. Em outros casos, o modelo pode ser uma referência a um ponto de extremidade HTTP parametrizado. Um provedor de plataforma de desenvolvedor deve fornecer informações suficientes sobre cada tipo de modelo para que eles possam ser referenciados e quaisquer opções expostas para uso em experiências do usuário. Mas, os próprios modelos podem ser alojados no local mais natural para seus casos de uso.
Engenheiros de plataforma ou especialistas em uma área específica escrevem modelos e os compartilham com as equipes de desenvolvimento para reutilização. Centralizar o uso desses modelos por meio de um sistema permite o autoatendimento do desenvolvedor e cria proteções que ajudam a impor a conformidade com padrões ou políticas organizacionais. Mais sobre isso quando abordarmos o orquestrador da plataforma do desenvolvedor daqui a pouco.
O gráfico da plataforma do desenvolvedor
Você pode pensar em um gráfico de plataforma de desenvolvedor como algo que permite associar entidades e modelos de vários provedores em um gráfico pesquisável. No entanto, os dados reais das entidades não precisam necessariamente ser persistidos diretamente em um banco de dados específico do gráfico. Em vez disso, as interações com os provedores podem ser armazenadas em cache junto com os metadados necessários para que tudo se encaixe.
O gráfico é poderoso quando usado com entidades comuns com as quais vários provedores podem contribuir. Por exemplo, uma lista de APIs pode vir de um produto como o Centro de API do Azure, mas talvez você também queira alimentar automaticamente implantações e ambientes de seus sistemas de implantação contínua. Com o tempo, você pode alternar entre diferentes sistemas de implantação ou até mesmo oferecer suporte a mais de um sistema de implantação. Contanto que cada sistema de implantação tenha um provedor de plataforma de desenvolvedor, você ainda poderá fazer a associação.
Cada uma de suas experiências de usuário que se acumulam a partir desse gráfico pode aproveitar uma API comum para potencializar a descoberta, a pesquisa, a governança e muito mais. Um orquestrador de plataforma de desenvolvedor pode aproveitar esse mesmo gráfico para que todas as ações executadas por um provedor de plataforma de desenvolvedor contribuam automaticamente com entidades disponíveis para a mesma API.
Orquestrador de plataforma de desenvolvedor
Um orquestrador de plataforma de desenvolvedor permite que desenvolvedores ou sistemas criem solicitações para executar uma ação usando um modelo. Ele não executa essas ações em si, mas coordena com um mecanismo de tarefa, mecanismo de fluxo de trabalho ou outro orquestrador para fazer isso. É uma das peças críticas que você vai querer ter certeza de que faz parte de sua base de autoatendimento. Ele permite que os desenvolvedores criem solicitações com um modelo ou executem uma ação sem permissão direta. Além disso, ao contrário do conceito de CI ou CD, essas ações não precisam estar relacionadas ao código-fonte do aplicativo.
Você pode usar GitHub Actions, Azure Pipelines ou outro mecanismo de fluxo de trabalho como seu orquestrador. Este é um lugar razoável para começar, mas você pode querer ter um pouco de abstração para permitir que diferentes tipos de modelos usem diferentes mecanismos subjacentes. Isso pode ser útil por alguns motivos:
- Primeiro, você provavelmente desejará ser capaz de escolher diferentes mecanismos de fluxo de trabalho e execução de tarefas ao longo do tempo sem precisar cortar rapidamente. Ao permitir mais de um mecanismo, você pode migrar ao longo do tempo ou simplesmente o uso do novo mecanismo para novas ações sem afetar as mais antigas.
- Alguns processos que você deseja ajudar a orquestrar podem exigir etapas manuais inicialmente, mesmo que você planeje automatizá-los totalmente posteriormente.
- Outras ações podem ter como alvo funções fora da equipe de desenvolvimento, como contas a pagar ou administrador de licenças. Mecanismos de baixo código, como o Power Automate, geralmente funcionam bem para essas funções.
- Outras ações podem ser tratadas por meio de solicitações HTTP simples em que criar algo tão capaz quanto GitHub Actions ou Azure Pipelines não é necessário ou econômico para dimensionar.
Felizmente, expandir a ideia de um provedor de plataforma de desenvolvedor para cobrir as etapas de automação de acionamento e rastreamento pode fornecer essa abstração necessária. Considere a seguinte ilustração:
Aqui está o conceito geral:
- Opcionalmente, os modelos podem especificar um conjunto de entradas que o usuário pode inserir. Quando um desenvolvedor aciona uma ação específica, ele escolhe um modelo (mesmo que não seja descrito dessa forma) e insere as entradas.
- Uma referência às entradas relacionadas ao modelo torna-se uma solicitação na API da plataforma do desenvolvedor.
- Depois que uma solicitação é enviada, um componente de roteamento e tratamento de solicitações no orquestrador começa a rastrear o ciclo de vida da solicitação. O modelo de roteamento e manipulação de solicitações de roteamento e manipulação de componentes na solicitação para o provedor de plataforma do desenvolvedor em que o modelo se originou.
- O provedor da plataforma do desenvolvedor executaria as etapas apropriadas para sua implementação.
- (Opcional) O provedor da plataforma do desenvolvedor atualiza o status da solicitação à medida que executa a ação.
- Depois que a solicitação for atendida, o provedor da plataforma do desenvolvedor poderá retornar um conjunto de entidades a serem adicionadas/atualizadas no gráfico da plataforma do desenvolvedor. Podem ser entidades específicas do provedor ou comuns.
Opcionalmente, para dar suporte a interações mais avançadas, os provedores de plataforma de desenvolvedor podem chamar a API da plataforma de desenvolvedor diretamente para obter mais entidades como entradas ou até mesmo solicitar outra ação relacionada.
Escolha um provedor de plataforma de desenvolvedor que use uma tarefa geral ou um mecanismo de fluxo de trabalho. Mais especificamente, você quer algo para unir o que você montou como parte dos sistemas de engenharia de software da Apply. Um fluxo de trabalho geral ou mecanismo de execução de tarefas para investir é um sistema de CI/CD.
Um exemplo usando GitHub Actions ou Azure Pipelines
Vejamos brevemente como um GitHub Actions ou Azure Pipelines como um provedor de plataforma de desenvolvedor funcionaria.
Para GitHub Actions, a chave para fazer isso funcionar é que um provedor de plataforma de desenvolvedor possa se conectar à instância especificada do GitHub e usar a API REST do Actions para disparar um evento de expedição de fluxo de trabalho para disparar uma execução de fluxo de trabalho. Cada fluxo de trabalho pode dar suporte a um conjunto de entradas adicionando uma configuração workflow_dispatch ao arquivo YAML do fluxo de trabalho. Os gatilhos do Azure DevOps são semelhantes e você também pode usar a API do Pipeline do Azure DevOps para execuções. Você provavelmente verá os mesmos recursos em outros produtos.
Esses fluxos de trabalho ou pipelines não precisam estar em repositórios de código-fonte do aplicativo. O conceito seria aproveitar esse fato para fazer algo assim:
- Os engenheiros de plataforma ou membros da equipe de DevOps podem manter os fluxos de trabalho/pipelines em um ou mais repositórios centrais aos quais os próprios desenvolvedores não têm acesso, mas o provedor da plataforma do desenvolvedor está configurado para usar. Esse mesmo repositório pode incluir scripts e snippets de IaC que os fluxos de trabalho/pipelines usam.
- Para permitir que esses fluxos de trabalho/pipelines interajam com o sistema downstream apropriado, as operações ou outros membros da equipe de engenharia da plataforma podem adicionar os segredos necessários no repositório central. Consulte a documentação do GitHub Actions e do Azure DevOps para obter detalhes sobre como fazer isso ou você pode optar por centralizar os segredos usando algo como o Azure Key Vault.
- Esses fluxos de trabalho/pipelines podem seguir um modelo em que publicam todas as entidades resultantes como um artefato de build/implantação (documentos do GitHub, documentos do Azure DevOps).
- Durante uma execução, o provedor da plataforma do desenvolvedor pode observar o estado do fluxo de trabalho/pipeline e atualizar o status do ciclo de vida no orquestrador até que ele seja concluído. Por exemplo, você pode usar web hooks com GitHub Actions e ganchos de serviço com Azure Pipelines para acompanhar atualizações .
- Depois de concluído, o provedor pode consumir o artefato publicado para inclusão no gráfico da plataforma do desenvolvedor, conforme necessário.
Por fim, você pode configurar esse provedor de plataforma de desenvolvedor para gerar um conjunto de modelos no gráfico da plataforma de desenvolvedor que fazem referência ao repositório e ao fluxo de trabalho/pipeline apropriados, juntamente com entradas para uma determinada tarefa.
A grande vantagem de usar um sistema de CI/CD é que eles geralmente são configurados para suportar a execução de CLIs arbitrárias, portanto, você não precisa de uma integração exclusiva e de primeira classe para tudo o que faz. Você pode adicioná-los ao longo do tempo, conforme necessário.
Muito do que é descrito neste exemplo se aplica a como outros tipos de provedores podem funcionar. Também é importante observar que o uso de GitHub Actions ou Azure Pipelines nesse contexto não exige que você também os use para seus pipelines de CI/CD reais.
Outros exemplos
Aqui estão alguns exemplos de outros tipos de provedores de plataforma de desenvolvedor que podem processar modelos.
| Exemplo | Descrição |
|---|---|
| Operações de controle do código-fonte | Em alguns casos, talvez seja necessário criar ou atualizar um repositório, enviar uma PR ou executar outra operação relacionada ao controle do código-fonte. Embora os mecanismos de fluxo de trabalho assíncronos gerais possam gerenciar esses tipos de operações, ser capaz de executar operações básicas do Git sem um pode ser útil. |
| Provisionadores de infraestrutura | Embora o GitHub Actions e o Azure Pipelines funcionem bem para gerenciar o provisionamento de infraestrutura, você também pode optar por integrações mais diretas. Um provedor dedicado pode simplificar a configuração e evitar sobrecarga. Serviços como Ambientes de Implantação do Azure ou Terraform Cloud estão mais diretamente focados em habilitar o provisionamento baseado em modelo de IaC e com segurança. Outros exemplos podem incluir coisas como criar namespaces do Kubernetes para aplicativos em clusters compartilhados ou usar git com fluxos de trabalho GitOps usando Flux ou Argo CD como um tipo específico de provedor. Ainda mais modelos centrados em aplicativos, como o projeto experimental de incubação Radius OSS com suas próprias CLIs, podem ter seus próprios provedores de plataforma de desenvolvedor ao longo do tempo. O principal é procurar e planejar a extensibilidade para que você possa se adaptar. |
| Andaime de aplicação / semeadura | Os modelos de aplicativos são uma parte importante de onde a engenharia de plataforma leva ao longo do tempo. Você pode dar suporte ao mecanismo de modelo de sua escolha fornecendo um provedor de plataforma de desenvolvedor dedicado projetado não apenas para estruturar uma árvore de origem do aplicativo, mas também para criar e enviar conteúdo para um repositório de código-fonte e adicionar as entidades resultantes ao gráfico. Cada ecossistema tem sua própria preferência de scaffolding de aplicativo, seja Yeoman, cookiecutter ou algo como a CLI do Desenvolvedor do Azure, portanto, o modelo de provedor aqui pode permitir que você dê suporte a mais de um de suas mesmas interfaces. Aqui, novamente, é a extensibilidade que é fundamental. |
| Processos manuais | Seja gerando automaticamente uma PR para aprovação manual ou etapas manuais de fluxo de trabalho para personas não desenvolvedoras responderem usando algo como o Power Platform, o mesmo modelo baseado em modelo pode ser usado em um provedor de plataforma de desenvolvedor. Você pode até mudar para etapas mais automatizadas ao longo do tempo. |
Embora talvez você não precise de todos esses provedores para começar, você pode ver como a extensibilidade por meio de algo como um provedor de plataforma de desenvolvedor pode ajudar seus recursos de automação a crescer ao longo do tempo.
Usuários e equipes
A engenharia de plataforma é inerentemente um assunto de vários sistemas, por isso é importante planejar como uma base de autoatendimento deve lidar com os problemas mais desafiadores com a integração desses sistemas. Aqui está uma estratégia para enfrentar desafios comuns com identidade, usuários e equipes.
| Recomendação | Descrição |
|---|---|
| Integre a API da plataforma do desenvolvedor diretamente ao seu provedor de identidade para obter a segurança ideal | Para proteger a API da plataforma do desenvolvedor, recomendamos a integração direta com um provedor de identidade como o Microsoft Entra ID, dada sua identidade robusta e os recursos de RBAC (controle de acesso baseado em função) do Entra ID. Há muitas vantagens em usar diretamente os SDKs e APIs nativos de um provedor de identidade (por exemplo, por meio da ID do MSAL Entra) em vez de por meio de uma abstração. Você pode impulsionar a segurança de ponta a ponta e contar com o mesmo modelo RBAC, garantindo que as políticas de acesso condicional sejam avaliadas continuamente (em vez de apenas no momento da entrada). |
| Usar integrações de grupo de provedor de identidade e logon único em sistemas downstream | Suas integrações de logon único (SSO) devem usar o mesmo provedor de identidade e locatário que você está usando para a API da plataforma do desenvolvedor. Além disso, certifique-se de aproveitar o suporte para protocolos como SCIM para conectar grupos de provedores de identidade (como grupos do AD). Vincular esses grupos de provedores de identidade a permissões de sistema downstream nem sempre é automático, mas, no mínimo, você pode associar manualmente grupos de provedores de identificação aos conceitos de agrupamento de cada ferramenta sem gerenciar manualmente a associação posteriormente. Por exemplo, você pode combinar o suporte ao Enterprise Managed User (EMU) do GitHub com o uso manual da capacidade de vincular grupos de provedores de identidade às equipes do GitHub. O Azure DevOps tem recursos semelhantes. |
Estabeleça o conceito de uma equipe além de um único grupo de provedores de identidade
À medida que sua jornada de engenharia de plataforma continua, você provavelmente descobrirá que os grupos de provedores de identidade são ótimos para gerenciar a associação, mas que vários grupos realmente precisam se unir para formar o conceito de uma equipe para RBAC (controle de acesso baseado em função) e agregação de dados.
No contexto da engenharia de plataforma, definimos uma equipe como um conjunto de pessoas em diferentes funções que estão trabalhando juntas. Para agregação de dados, a ideia de uma equipe multifuncional é fundamental para potencializar a descoberta e o acúmulo de informações em locais como painéis de relatórios. Por outro lado, um grupo é um conceito geral de provedor de identidade para um conjunto de usuários e é projetado com a ideia de adicionar várias pessoas a uma função específica, e não o contrário. Com o RBAC, uma equipe, portanto, pode se relacionar com vários grupos de provedores de identidade por meio de funções diferentes.
A fonte dos dados da sua equipe pode vir de alguns lugares diferentes. Por exemplo, se você estiver usando as equipes como padrão de código (TaC), um provedor de plataforma de desenvolvedor poderá observar as alterações de arquivo em um repositório e armazená-las em cache em um perfil de usuário e no repositório de metadados da equipe. Ou você pode integrar diretamente com algo como um Projeto do Centro de Desenvolvimento do Azure que já tem esses constructos RBAC principais disponíveis.
Estabeleça um modelo para integração com sistemas downstream no nível da equipe ou do usuário
Embora algumas ferramentas/serviços de desenvolvedor e operações integrem e usem nativamente conceitos de provedor de identidade diretamente, muitos abstrairão isso em sua própria representação de um grupo ou usuário (mesmo com SSO). Além de permitir o acesso entre ferramentas, essa realidade também pode representar problemas para a agregação de dados. Especificamente, você pode descobrir que as APIs no sistema downstream usam seus próprios identificadores em vez de identificadores de provedor de identidade (exemplo: a ID do objeto na ID do Entra não é usada diretamente). Isso dificulta a filtragem e a associação de dados no nível do usuário ou da equipe, a menos que você possa mapear entre diferentes IDs.
Abordar diferenças no nível da equipe e do grupo
Padrões como TaC podem permitir que você armazene e acesse relacionamentos entre os identificadores de equipe ou grupo de cada sistema para que você possa mapear entre eles. Para recapitular, um repositório Git seguro e auditável se torna a fonte de uma equipe e as PRs fornecem uma interface de usuário controlada para fazer atualizações. Os sistemas de CI/CD podem atualizar os sistemas downstream e persistir os relacionamentos de identificador relacionados para a equipe usada para fazer isso.
Por exemplo, isso permite que as seguintes relações sejam armazenadas em chamadas de API:
Se você preferir usar uma fonte de dados diferente de arquivos em um repositório de suas equipes, esse mesmo conceito geral pode ser aplicado usando o orquestrador da plataforma do desenvolvedor para realizar a mesma coisa. Nesse modelo, um provedor de plataforma de desenvolvedor para a fonte dos dados da equipe pode disparar um evento de atualização de equipe que todos os outros provedores recebem e agem conforme apropriado.
Resolver desafios de ID de usuário
Outro desafio relacionado ao acesso e agregação de dados são as diferenças de ID do usuário. Como no caso da equipe, se você usar uma integração de sistema para sistema para consultar dados sobre um usuário, não poderá presumir que a ID nativa do provedor de identidade (por exemplo, ID de objeto para ID de entrada) dá suporte a uma determinada API. Aqui, novamente, armazenar um mapeamento para um ID de usuário que está acessando dados por meio da API da plataforma do desenvolvedor pode ajudar. Por exemplo, considere o GitHub:
Para cada sistema, se você puder fazer uma pesquisa de um ID de usuário em outro sistema por meio de uma API sem um token de usuário, um determinado provedor de plataforma de desenvolvedor poderá gerar esse mapeamento em tempo real. Em alguns casos, isso pode ser complicado, pois talvez seja necessário executar essa operação em massa e armazenar em cache os resultados para referência para manter o desempenho.
Fallback no uso de vários tokens de usuário
Para situações em que os provedores precisam acessar dados no nível do usuário sem uma maneira de fazer a conversão de ID do usuário que funcione, a API da plataforma do desenvolvedor pode ser configurada para gerenciar vários tokens de usuário. Por exemplo:
- A API da plataforma do desenvolvedor pode dar suporte a um cache de tokens de usuário específicos do provedor para uso com sistemas downstream.
- Todas as interações com um determinado provedor acionadas pela API seriam incluídas no token de usuário do provedor, se disponível.
- Para lidar com o caso em que nenhum token de usuário estava disponível, o provedor dispararia um fluxo OAuth para obter um.
- Para começar, a API da plataforma do desenvolvedor passaria de volta um URI de autenticação para um fluxo OAuth com um URI de redirecionamento que foi passado para o provedor. O URI passado incluiria um código de uso único / nonce.
- Em seguida, a API retorna uma resposta "não autenticada" com o URI.
- Qualquer UX pode usar esse URI para conduzir o fluxo de autenticação apropriado em um navegador.
- Quando o redirecionamento acontecer, a plataforma do desenvolvedor receberá o token de usuário necessário e o armazenará em cache para referência futura junto com o ID do usuário.
- O cliente poderia então repetir a chamada à API, que seria bem-sucedida.
Esse conceito descreve uma maneira de lidar com a autenticação complicada, pois você pode reutilizar IDs sempre que possível e não precisa manter URIs de redirecionamento separados por sistema downstream.
Use links diretos com reconhecimento de contexto para ferramentas e sistemas de relatórios
Até este ponto, falamos sobre o aspecto de automação do espaço do problema. Isso por si só pode ajudar muito, pois sua interface do usuário pode usar valores nas entidades retornadas durante a automação para criar links profundos em outros sistemas para a equipe.
Mesmo quando não relacionados à automação, os provedores de plataforma de desenvolvedor podem emitir qualquer tipo de necessidade de entidade. No entanto, você geralmente não deseja trazer todos os dados detalhados de toda a sua plataforma de desenvolvedor interna para o gráfico da plataforma do desenvolvedor. Painéis em soluções de observabilidade como Grafana, Prometheus, DataDog ou inteligência de código em produtos como SonarQube e recursos nativos em pacotes de DevOps como GitHub e Azure DevOps são muito capazes. Em vez disso, a melhor abordagem geralmente é criar links profundos para esses outros sistemas. Suas entidades podem fornecer informações suficientes para criar links sem conter diretamente informações detalhadas, como conteúdo de log.
Para casos em que você deseja dados agregados e resumidos entre ferramentas ou precisa gerar métricas personalizadas, as soluções de relatório Power BI ou Microsoft Fabric podem ser seu próximo porto de escala. Para mesclar os dados da equipe, você pode se conectar ao banco de dados da sua Fundação ou passar por uma API de plataforma de desenvolvedor. Por exemplo, conforme descrito em Planejar e priorizar, um local em que você pode querer um painel personalizado é medir o sucesso de sua plataforma interna de desenvolvedor.
Seja seletivo com cada experiência extra que você construir
Embora possa ser atraente recriar recursos existentes em algo como um portal comum, lembre-se de que você também precisará mantê-lo. Esta é a área em que seguir uma mentalidade de produto é importante. As interfaces de estilo de painel são fáceis de conceber e entender, mas seus desenvolvedores podem encontrar mais valor em outro lugar.
Dito isso, o modelo aqui permite que você use dados agregados no gráfico da plataforma do desenvolvedor para criar experiências de usuário personalizadas. As entidades devem ter suporte interno para que possam se vincular a um usuário ou equipe. Isso permite que a API da plataforma do desenvolvedor defina o escopo da saída (juntamente com o uso de indexação e cache).
No entanto, mesmo quando você precisa criar uma experiência do usuário personalizada em vez de um link direto, puxar todos os dados para o gráfico da plataforma do desenvolvedor normalmente ainda não é a melhor abordagem. Por exemplo, considere uma situação em que você pode querer exibir logs em sua experiência do usuário que já tem uma página inicial bem definida e gerenciada. Use informações nas entidades relacionadas para ajudar sua experiência do usuário a coletar informações diretamente de sistemas downstream.
Para começar, talvez seja necessário usar uma integração de sistema para sistema para se conectar, mas depois de implementar um dos modelos descritos em usuários e equipes, você pode usar quaisquer IDs de usuário/equipe downstream armazenadas ou tokens de autenticação de usuário, se necessário.
Aqui estão alguns exemplos de experiências comuns a serem consideradas:
| Exemplo | Descrição |
|---|---|
| Descoberta e exploração | Como disse um profissional de engenharia de plataforma: "O que retarda os projetos é a comunicação, não as habilidades do desenvolvedor". – Daniel, engenheiro de nuvem, Fortune 500 Media Company. Como o software é um esporte de equipe, criar uma interface de usuário para ajudar a descobrir as equipes e as entidades que elas possuem é normalmente uma das primeiras coisas a serem abordadas. A pesquisa, a descoberta e os documentos entre equipes ajudam a promover a reutilização e auxiliam na colaboração para fornecimento ou suporte interno. As equipes também se beneficiam de ter um balcão único para encontrar coisas que possuem, incluindo ambientes, repositórios e outros recursos, como documentos. |
| Registro manual de ambientes ou recursos | Embora muitas coisas possam ser provisionadas e rastreadas por meio do orquestrador da plataforma do desenvolvedor, talvez você também queira registrar recursos ou ambientes que já existem ou ainda não estão automatizados. Um provedor simples que obtém informações de um repositório git e adiciona informações ao gerenciamento de recursos/ambiente pode ser útil aqui. Se você já possui um catálogo de software, isso também se torna uma forma de integrá-lo ao modelo. |
| Um catálogo de API | As APIs de rastreamento que os desenvolvedores devem usar podem ajudar muito. Se você ainda não tem algo, pode até começar com um repositório Git simples com uma série de arquivos que representam APIs, seu status, usar PRs para gerenciar seu fluxo de trabalho de aprovação. Eles podem ser adicionados ao gráfico da plataforma do desenvolvedor para que possam ser exibidos ou associados a outras entidades. Para recursos mais robustos, você pode integrar algo como o Centro de API da Microsoft ou outro produto. |
| Conformidade da licença | Em alguns casos, você também pode querer fornecer visibilidade da conformidade da licença de software e do consumo de licenças. As plataformas de desenvolvedor também podem adicionar a automação necessária para consumir licenças, mas mesmo que as licenças sejam atribuídas manualmente (por exemplo, por meio de um processo de PR em um repositório Git), a visibilidade do desenvolvedor sobre o que eles têm (e a capacidade do administrador de ver tudo). |
| Uma visão centrada em aplicativos do Kubernetes | Quando você usa um cluster compartilhado do Kubernetes, pode ser difícil para os desenvolvedores encontrar e entender o estado de seus aplicativos por meio da UX do administrador do cluster. Diferentes organizações podem optar por lidar com esse problema de maneira diferente, mas usar um namespace para representar um aplicativo é uma maneira bem conhecida de fazer isso. A partir daí, você pode usar entidades para estabelecer associações entre o namespace do aplicativo no cluster e uma equipe e criar uma visão mais focada no desenvolvedor do status do aplicativo e fornecer links profundos para outras ferramentas ou interfaces do usuário da Web. |
Experiências do usuário
Diferentes funções em sua organização têm ferramentas ou serviços que representam um centro de gravidade para seu trabalho diário. A atração desses sistemas pode dificultar que novas experiências de usuário fora desses centros de gravidade ganhem força. Em um mundo perfeito, desenvolvedores, operações e outras funções podem continuar a trabalhar em um ambiente que faça sentido para eles - geralmente aqueles que já estão usando.
Com isso em mente, planejar várias interfaces de usuário à medida que você avança em sua jornada de engenharia de plataforma é uma boa ideia. Isso também pode fornecer uma oportunidade de começar simples, provar valor e crescer em direção a interfaces mais complexas conforme a necessidade.
Integre o que você tem
Se você leu os artigos Aplicar sistemas de engenharia de software e Refinar plataforma de aplicativos, provavelmente identificou os sistemas que deseja continuar a usar. Em ambos os casos, avalie se você pode aprimorar e estender o que tem antes de começar a criar novas experiências do zero. (Pergunte a si mesmo: as pessoas reagirão melhor a outra nova experiência do usuário ou a uma versão melhorada de algo que têm agora?)
Algumas das ferramentas, utilitários ou aplicativos da web que você deseja continuar usando serão personalizados e são bons candidatos para aprimoramento. Mas não se esqueça de prestar atenção se suas ferramentas e serviços favoritos têm um modelo de extensibilidade que você pode usar. Você obterá muitos benefícios ao começar por aí. Isso pode eliminar dores de cabeça de manutenção e segurança e permitir que você se concentre no problema que está tentando resolver
Por exemplo, você pode estender as seguintes superfícies que já está usando:
- Editores e IDEs.
- Seu pacote de DevOps.
- As CLIs também são cada vez mais extensíveis.
- Ambientes com pouco ou nenhum código, como o Power Pages.
Cada um pode fornecer um ponto de partida melhor para uma determinada função do que algo que você configurou do zero, já que são centros de gravidade existentes. Ter uma API de plataforma de desenvolvedor comum como linha de base permitirá que você troque coisas, experimente e mude ao longo do tempo.
Considere extensões de editor da Web para criar um portal do desenvolvedor
Se você estiver procurando por uma experiência baseada na Web para desenvolvedores, lembre-se de que uma tendência recente são as versões baseadas na Web de editores e IDEs. Muitos, como aqueles que usam o VS Code, têm suporte a extensão. Com o VS Code, tudo o que você cria para essas experiências na Web é traduzido localmente para um benefício duplo.
Além de serviços como o GitHub Codespaces, o vscode.dev é uma versão web gratuita do editor VS Code sem computação, mas inclui suporte para determinados tipos de extensões, incluindo aquelas que usam exibições da Web para interface do usuário personalizada.
Mesmo que seus desenvolvedores não estejam usando o VS Code em si, os padrões de experiência do usuário são bem conhecidos e podem ser encontrados em outras ferramentas de desenvolvedor. O uso vscode.dev pode fornecer uma base baseada na Web conveniente e familiar para experiências de desenvolvedor, além da própria ferramenta.
Eles podem atuar como um portal focado no desenvolvedor de uma forma familiar que também pode ser traduzida para uso local.
ChatOps
Outra oportunidade que muitas vezes é negligenciada é a implementação de uma interface ChatOps. Dado o aumento de interfaces baseadas em bate-papo devido ao surgimento de produtos de IA como ChatGPT e GitHub Copilot, comandos de ação ou comandos de barra podem fornecer uma maneira útil de acionar fluxos de trabalho de automação, verificar status e muito mais. Dado que a maioria das plataformas de CI/CD de aplicativos tem suporte pronto para uso para sistemas como Microsoft Teams, Slack ou Discord, essa pode ser uma maneira natural de se integrar a outra interface do usuário que os desenvolvedores e as funções de operações relacionadas usam todos os dias. Além disso, todos esses produtos têm um modelo de extensibilidade.
Investindo em um novo portal do desenvolvedor
Supondo que você não tenha um portal ou interface existente que deseja usar como base, talvez decida criar um novo portal do desenvolvedor. Pense nisso como um destino e não como um ponto de partida. Se você ainda não tem uma equipe de desenvolvimento trabalhando com você, começar esse esforço é a hora de fazê-lo. Cada organização é diferente, portanto, não há uma resposta única para o que deve estar nesse tipo de experiência. Como resultado, não há uma resposta de fato para um produto pré-embalado que você pode criar e usar como está para algo assim hoje.
Para opções auto-hospedadas personalizadas, as estruturas gerais do portal da Web não são novas e suas equipes de desenvolvimento podem já estar usando uma que você pode explorar. Se você estiver tentando divulgar algo na frente de seus usuários para comentários antecipados, poderá até começar com algo tão simples quanto o Power Pages de baixo código para se conectar à API comum da plataforma de desenvolvedor.
Os esforços mais recentes do portal do desenvolvedor são mais opinativos. Por exemplo, Backstage.io é um kit de ferramentas de portal de desenvolvedor personalizado inicialmente criado para atender às necessidades do Spotify. Ele inclui uma CLI para ajudar a inicializar sua árvore de origem, assim como create-react-app faz para React.js.
Como um kit de ferramentas do portal, ele requer trabalho para ser instalado e a personalização requer conhecimento de TypeScript, Node.js e React. No entanto, o melhor disso é que, como um kit de ferramentas, você pode mudar quase tudo. Ele também possui seu próprio catálogo de software e mecanismo de modelagem, mas seu uso não é necessário e possui uma maneira bem definida de trazer novos códigos de 1ª e 3ª partes chamados plug-ins.