Arquitetura de plataforma de autoatendimento do desenvolvedor
Uma experiência de autosserviço para desenvolvedores depende de uma combinação de conceitos, padrões e ferramentas, abrangendo tecnologias personalizadas, prontas para uso e de código aberto. O objetivo é capacitar os desenvolvedores com a execução e o provisionamento de tarefas controladas, mantendo a visibilidade centralizada. O foco principal deve ser em tarefas que são entediantes ou muito complexas para os desenvolvedores lidarem de forma independente.
Componentes da plataforma de autoatendimento do desenvolvedor
Uma base de autosserviço do desenvolvedor consiste em vários componentes-chave que trabalham juntos para simplificar e automatizar os fluxos de trabalho do desenvolvedor. Esses componentes incluem a API da plataforma do desenvolvedor, o gráfico da plataforma do desenvolvedor, o orquestrador da plataforma do desenvolvedor, os provedores da plataforma do desenvolvedor e o perfil do usuário e os metadados da equipe.
A API da Plataforma do Desenvolvedor atua como o ponto central de interação, servindo como uma interface contratual entre as experiências do usuário e outros sistemas. Uma API de plataforma de desenvolvedor deve permitir o acesso a dados e conduzir ações de provisionamento por meio de várias interfaces de usuário. Ele serve como a principal camada de autenticação e segurança, restringindo o acesso a APIs subjacentes e brutas, juntamente com os dados e operações correspondentes. A API gerencia perfis de usuário, funções dentro da plataforma e identificadores de provedor de identidade principal para garantir o controle de acesso adequado.
Complementando a API da Plataforma do Desenvolvedor está o Gráfico da Plataforma do Desenvolvedor, uma estrutura de dados segura e gerenciada que facilita a descoberta e a associação de entidades e modelos dentro da plataforma. As entidades agregam dados de várias fontes, enquanto os modelos orientam as entradas do usuário para automação.
O Developer Platform Graph permite associar entidades e modelos de vários provedores em uma estrutura pesquisável. Embora os dados dessas entidades não precisem ser armazenados diretamente em um banco de dados gráfico, as interações com os provedores podem ser armazenadas em cache junto com os metadados necessários. Este gráfico torna-se especialmente valioso quando se trabalha com entidades comuns contribuídas por vários fornecedores. Por exemplo, as APIs podem vir do Centro de API do Azure, enquanto implantações e ambientes podem ser extraídos de sistemas de implantação contínua. O gráfico potencializa as experiências do usuário por meio de uma API comum, permitindo descoberta, pesquisa e governança.
Para executar ações baseadas em modelos, o Developer Platform Orchestrator roteia e rastreia solicitações, coordenando-se com Provedores de Plataforma de Desenvolvedores especializados que se integram com sistemas downstream. O orquestrador permite que desenvolvedores ou sistemas solicitem ações usando modelos, sem executar as ações diretamente. Ele coordena com um mecanismo de tarefas, mecanismo de fluxo de trabalho ou outro orquestrador para executar as ações. Esse componente é essencial para habilitar o autosserviço, pois permite que os desenvolvedores acionem ações sem precisar de permissões diretas. Ao contrário do CI/CD, essas ações não se limitam ao código-fonte do aplicativo. Mecanismos de fluxo de trabalho como GitHub Actions ou Azure Pipelines podem servir como orquestradores, mas a abstração pode ser útil para dar suporte a diferentes mecanismos ao longo do tempo. Essa flexibilidade permite a migração do mecanismo, suporta etapas manuais para processos que podem ser automatizados posteriormente e acomoda ações direcionadas a funções que não são de desenvolvimento (por exemplo, contas a pagar). Além disso, tarefas mais simples podem ser tratadas por meio de solicitações HTTP, evitando a necessidade de mecanismos complexos.
Os Provedores de Plataforma de Desenvolvedor gerenciam a lógica para operações de Criação, Leitura, Atualização e Exclusão (CRUD) em entidades e a execução de solicitações de ação, suportando diversos fluxos de trabalho e serviços. Os provedores introduzem funcionalidades na API por meio de um modelo de provedor extensível, permitindo recursos importantes como automação e agregação de dados. Este modelo promove acoplamento solto, permitindo a integração incremental de novas funcionalidades e melhorando a capacidade de manutenção. Ao promover uma mentalidade de fonte interna, a funcionalidade da plataforma pode ser contribuída e mantida por diferentes equipes, minimizando a carga de manutenção sobre as equipes centrais. Embora seja essencial revisar o código do provedor e gerenciar o acesso com cuidado, essa abordagem conectável ajuda a dimensionar o esforço de desenvolvimento em toda a organização.
A fundação também inclui recursos para gerenciar Perfil de Usuário e Metadados de Equipe, que vinculam informações individuais e de equipe a contas hospedadas por um provedor de identidade, como o Microsoft Entra ID. Esses metadados são usados para agrupamento e controle de acesso dentro da API da plataforma do desenvolvedor. Embora seja possível armazenar essas informações no Developer Platform Graph, separá-las garante clareza.
Uma base de autosserviço do desenvolvedor é acessível por meio de uma interface de usuário/experiência do usuário (UI/UX) centralizada. Oferecer um ponto de acesso unificado simplifica as interações para os desenvolvedores, facilitando o uso de fluxos de trabalho e recursos de forma contínua e intuitiva.
Uma base de autosserviço para desenvolvedores não precisa ser totalmente construída desde o início. Em vez disso, ele serve como um guia conceitual para os recursos a serem almejados ao longo do tempo. As implementações iniciais podem ser simplificadas, usando ferramentas, interfaces ou classes existentes para abordar as prioridades mais urgentes identificadas através do feedback do cliente. Ao começar pequeno e iterar, a fundação pode evoluir para atender efetivamente a novas demandas.
Principais conceitos do provedor de plataforma para desenvolvedores
Em uma plataforma de desenvolvedor, o gerenciamento eficaz e a orquestração de recursos dependem do uso de entidades juntamente com suas propriedades e modelos. Esses conceitos-chave fornecem estrutura e automação, permitindo uma integração perfeita entre diferentes provedores e facilitando fluxos de trabalho e governança consistentes.
Entidades
As entidades são os principais objetos que um desenvolvedor ou sistema precisa rastrear, atualizar, apresentar ou agir dentro da plataforma interna do desenvolvedor. Estas entidades podem ter relações entre si, formando um gráfico que fornece informações cruciais sobre a plataforma. Os provedores de plataforma de desenvolvedor podem produzir entidades para dar suporte a vários recursos principais, como descobrir recursos externos, executar análise de dependência ou revelar informações de propriedade e mantenedores. Uma interface de provedor bem definida simplifica a integração, o teste e a implantação, permitindo que as equipes de desenvolvedores operem de forma independente.
Propriedades Comuns
Para gerenciar entidades de forma eficaz, é útil definir um conjunto de propriedades comuns. Algumas propriedades sugeridas incluem um identificador exclusivo, nome, provedor de origem e associações opcionais para usuários, equipes ou outras entidades. Essas propriedades são importantes para RBAC (controle de acesso baseado em função), descoberta e agregação de dados. A implementação do RBAC desde o início é fundamental para a segurança e o dimensionamento da plataforma ao longo do tempo. As associações de usuários e equipes são especialmente valiosas, pois ajudam na descoberta e colaboração, permitindo reutilização, suporte e fornecimento interno eficientes dentro da plataforma.
Entidades Comuns e Específicas do Fornecedor
Você também deve definir um conjunto de entidades comuns, de alto nível e normalizadas que vários provedores podem produzir. Isso pode incluir ambientes, recursos, APIs, repositórios, componentes e ferramentas. Essas entidades devem ser conceituais, concentrando-se na categorização ampla (como ambientes) em vez dos detalhes técnicos granulares (por exemplo, infraestrutura interna). Essa visão de alto nível facilita a descoberta, permitindo a agregação de dados ao longo do tempo enquanto aponta para detalhes de nível inferior fora do sistema. Além disso, à medida que sua plataforma evolui, você pode precisar acomodar um conjunto crescente de tipos de entidades específicas do provedor para atender a diversos casos de uso.
Modelos
Os modelos são projetados para impulsionar ações como provisionamento de infraestrutura, criação de repositório ou outros processos de longa execução. Esses modelos estão disponíveis por meio de provedores de plataforma de desenvolvedor e incluem propriedades comuns, como associações de entidades e entradas necessárias (por exemplo, nomes de recursos). Os modelos podem representar vários formatos, incluindo modelos de infraestrutura como código (IaC), modelos de aplicativo ou scripts parametrizados. Eles geralmente são específicos do provedor, com representações diferentes dependendo da tecnologia em uso. Exemplos dessas representações incluem modelos Terraform ou Bicep, gráficos Helm, fluxos de trabalho parametrizados de Ações do GitHub, Pipelines do Azure, scripts simples ou formatos personalizados adaptados a ecossistemas de provedores específicos.
Embora os modelos não precisem ser armazenados centralmente, eles devem ser acessíveis por meio de um provedor para garantir acesso consistente em toda a plataforma. Eles podem existir em diferentes repositórios, registros ou catálogos, dependendo do caso de uso. Por exemplo, os repositórios de modelos do GitHub podem ser usados para modelos de aplicativos, enquanto os modelos do IaC podem residir em um repositório de catálogo restrito que os desenvolvedores acessam indiretamente por meio de ferramentas como os Ambientes de Implantação do Azure. Outros modelos de IaC podem ser armazenados em um registro de artefato Open Container Initiative (OCI), como gráficos Helm. Em alguns casos, um modelo pode simplesmente fazer referência a um ponto de extremidade HTTP parametrizado.
Os engenheiros de plataforma ou especialistas de domínio normalmente criam esses modelos e os compartilham com as equipes de desenvolvimento para reutilização. Centralizar o uso de modelos dentro de um sistema facilita seu acesso enquanto aplica padrões e políticas organizacionais. Esse processo ajuda a manter o controle e a conformidade em toda a plataforma, ao mesmo tempo em que capacita os desenvolvedores a trabalhar de forma mais eficiente.
Ações do GitHub como provedores de plataforma
Para ilustrar como um provedor funciona, vamos considerar as Ações do GitHub e os Pipelines do Azure. Qualquer um deles pode servir como um provedor de plataforma de desenvolvedor acionando fluxos de trabalho ou execuções de pipeline por meio de suas respetivas APIs, como a API REST de Ações do GitHub ou a API de Pipeline do Azure DevOps. Esses fluxos de trabalho ou pipelines não precisam ser alojados em repositórios de código-fonte de aplicativos, permitindo que os engenheiros de plataforma os mantenham em repositórios centrais e privados. Nesse modelo, os desenvolvedores não têm acesso direto aos fluxos de trabalho, mas podem usar um provedor de plataforma de desenvolvedor para interagir com eles. O provedor pode gerenciar segredos necessários, como credenciais ou chaves de API, integrando-se a serviços como o Azure Key Vault. À medida que os fluxos de trabalho são executados, o provedor rastreia seu estado, usando webhooks para Ações do GitHub e ganchos de serviço para Pipelines do Azure para monitorar o progresso. Quando o fluxo de trabalho for concluído, todos os artefatos produzidos, como resultados de compilação ou implantação, serão capturados e publicados. Esses artefatos, juntamente com parâmetros de entrada e referências aos fluxos de trabalho, podem ser adicionados ao gráfico da plataforma do desenvolvedor. Essa abordagem também permite flexibilidade no uso de CLIs arbitrárias, suportando uma ampla gama de tarefas de automação ao longo do tempo. Além disso, o uso de Ações do GitHub ou Pipelines do Azure nesse contexto é independente de sua função tradicional em CI/CD, fornecendo uma aplicabilidade mais ampla para gerenciar vários processos e modelos.
Existem outros tipos de provedores de plataforma de desenvolvedor, que podem lidar com várias tarefas por meio de modelos. Para operações de controle do código-fonte, os provedores podem ajudar a gerenciar tarefas do Git, como criar repositórios, enviar PRs ou outras operações do Git sem depender de mecanismos gerais de fluxo de trabalho. O provisionamento de infraestrutura pode ser simplificado por meio de provedores dedicados, como Ambientes de Implantação do Azure ou Terraform Cloud, com foco na Infraestrutura como Código (IaC) com segurança e eficiência. Os provedores de scaffolding de aplicativos, como a CLI do Azure Developer, dão suporte à criação de árvores de origem de aplicativos e ao envio delas para repositórios de origem, adicionando flexibilidade para diferentes ecossistemas. Processos manuais, como gerar solicitações pull (PRs) ou automatizar fluxos de trabalho para não desenvolvedores, também podem ser gerenciados por meio de provedores baseados em modelos, permitindo a automação gradual. Esses exemplos destacam como a extensibilidade e a adaptabilidade em provedores de plataforma de desenvolvedor podem aprimorar os recursos de automação ao longo do tempo.