Gerencie análises em escala de nuvem

Hoje, o DevOps mudou a cultura de como as pessoas pensam e trabalham, acelerando a taxa na qual as empresas percebem valor, ajudando indivíduos e organizações a desenvolver e manter práticas de trabalho sustentáveis. O DevOps combina desenvolvimento e operações e é frequentemente associado a ferramentas de engenharia de software que suportam práticas de integração contínua (CI) e entrega contínua (CD). Essas ferramentas e práticas incluem gerenciadores de código-fonte (como Git, Apache Subversion ou Team Foundation Version Control) e gerenciadores automáticos de compilação e entrega (como Azure Pipelines ou GitHub Actions).

DevOps combinado com observabilidade é fundamental para fornecer uma plataforma ágil e escalável. O DevOps dá às equipes a capacidade de implementar controle de código-fonte, pipelines de CI/CD, infraestrutura como código, fluxos de trabalho e automação. Embora a observabilidade permita que proprietários de empresas, engenheiros de DevOps, arquitetos de dados, engenheiros de dados e engenheiros de confiabilidade do local detetem, prevejam, previnam e resolvam problemas de forma automatizada e evitem eliminar o tempo de inatividade que, de outra forma, quebraria a análise de produção e a IA.

Controlo de origem

O controle do código-fonte garante que o código e as configurações persistam e que as alterações sejam controladas e versionadas. A maioria dos sistemas de controle de origem também tem processos internos para revisão e trabalho em diferentes ramificações de um repositório de código. Atualmente, o tipo de controle de origem mais popular atualmente é o Git, que é um sistema de controles de versão distribuída que permite que os indivíduos trabalhem offline e sincronizem com repositórios centrais. Os fornecedores de Git normalmente também usam ramificações e seguem as orientações de pull request para suportar o fluxo de alteração e revisão.

As branches de código isolam alterações ou desenvolvimento de funcionalidades sem afetar outros trabalhos que decorrem ao mesmo tempo. O uso de ramificações deve ser promovido para desenvolver recursos, corrigir bugs e experimentar novas ideias com segurança. As solicitações pull mesclam as alterações feitas de uma ramificação na ramificação padrão e dão suporte a um processo de revisão controlado. Para fins de segurança, a ramificação principal deve usar solicitações pull para garantir revisões de código.

Pipelines de CI/CD

O CI permite que as equipes testem e criem automaticamente o código-fonte e permite iterações rápidas e loops de feedback para garantir alta qualidade de código em CD. Pipelines são maneiras de configurar o CI das alterações (código de software ou código de infraestrutura) e o CD das alterações empacotadas/compiladas. Isso também é conhecido como build and release. CD descreve a implantação automática de aplicativos em um ou mais ambientes. O CD geralmente segue um processo de CI e usa testes de integração para validar todo o aplicativo.

Os pipelines podem conter vários estágios com várias tarefas e podem ter fluxos de aprovação simples a complexos para garantir a conformidade e a validação. Com base na preferência, os pipelines também podem ser configurados com vários gatilhos automáticos. Para implantação em escala empresarial e IA, as etapas de produção devem sempre ter pré-aprovação humana, e isso é incorporado ao modelo de operação. Os pipelines de CI/CD devem ser criados com GitHub Actions ou Azure Pipelines e devem incluir gatilhos automatizados.

Infraestrutura como código

O termo código no IaC geralmente levanta preocupações para a equipe de TI sem experiência em desenvolvedores, mas o IaC não se refere a escrever código da maneira como os desenvolvedores de software típicos o fazem. No entanto, adota muitas das mesmas ferramentas e princípios dos processos de desenvolvimento de software para fornecer infraestrutura em um formato previsível.

O IaC ajuda a infraestrutura a ser provisionada, configurada e gerenciada como parte de um pipeline de DevOps com controles completos de alterações, histórico de auditoria, testes, validações e processos de aprovação, garantindo que as tarefas possam ser delegadas às funções apropriadas para o projeto sem comprometer a segurança e a conformidade.

As duas abordagens à IaC são declarativas e imperativas:

• Declarativo refere-se a especificar o estado desejado da infraestrutura e ter um mecanismo de orquestração executando as ações necessárias para alcançar o estado desejado. No Azure, isso é feito com modelos do Azure Resource Manager. Camadas de abstração de terceiros como Terraform também estão disponíveis para essa abordagem.

• A abordagem imperativa refere-se à execução de comandos específicos em uma ordem definida. Para o Azure, isso pode ser alcançado com a interface de linha de comando ou PowerShell, mas kits de desenvolvedor de software de linguagem de programação nativa, por exemplo, .NET, Python e Java, também estão disponíveis se soluções integradas forem necessárias.

Nos modelos do Azure Resource Manager, o provisionamento principal está na seção de recursos e a configuração dos recursos individuais é definida em uma seção de propriedades . Para um Azure Data Lake Storage Gen2, a configuração tem a seguinte aparência:

{
    "$schema": "https://schema.management.azure.com/schemas/2015-01-01/deploymentTemplate.json#",
    "contentVersion": "1.0.0.0",
    "resources": [
        {
            "type": "Microsoft.MachineLearningServices/workspaces/datastores",
            "name": "[concat(parameters('workspaceName'), '/', parameters('datastoreName'))]",
            "apiVersion": "2020-05-01-preview",
            "location": "[parameters('location')]",
            "properties": {
                "DataStoreType": "adls-gen2",
                "SkipValidation": "[parameters('skipValidation')]",
                "ClientId": "[parameters('clientId')]",
                "ClientSecret": "[parameters('clientSecret')]",
                "FileSystem": "[parameters('fileSystem')]",
                "AccountName": "[parameters('accountName')]",
                "TenantId": "[parameters('tenantId')]",
                "ResourceUrl": "[parameters('resourceUrl')]",
                "AuthorityUrl": "[parameters('authorityUrl')]"
            }
        }
    ]
}

Fluxos de trabalho e automação

As equipes devem usar pipelines de CI/CD em vários estágios para garantir que o código desenvolvido esteja sem erros e pronto para produção. Algumas práticas recomendadas são ter um ambiente de desenvolvimento, um ambiente de teste e um ambiente de produção. Esses estágios também devem ser refletidos no Azure usando serviços separados para cada ambiente.

A equipe da plataforma é responsável por fornecer e manter modelos de implantação para escalar rapidamente dentro de uma organização e simplificar implantações para equipes não familiarizadas com o IaC. Esses modelos servem como uma linha de base para novos artefatos dentro do cenário e precisam ser mantidos ao longo do tempo para representar as melhores práticas e padrões comuns dentro da empresa.

As implantações para teste e produção só devem ser gerenciadas por meio de um pipeline de CI/CD e uma conexão de serviço com permissões elevadas para impor práticas recomendadas comuns (por exemplo, modelos do Azure Resource Manager).

Próximos passos

Automação da plataforma