Proteção do projeto: ambientes de provisionamento
Esta série de breves artigos é composta por algumas coisas que aprendi ao longo dos últimos anos executando projetos baseados na área em que nós (assumindo que você está lendo isso vindo da mesma parte da indústria que eu 🙂) trabalhar.
Se você está apenas se deparando com isso, a série aborda alguns fatores que são importantes para um projeto :
- Não deve haver ” projeto por comitê. “
- Ninguém mais que a equipe de desenvolvimento principal deve ser capaz de fornecer desenvolvimento, preparação e produção.
- Ninguém deve ser capaz de escrever para produção, exceto a equipe de desenvolvimento (e mesmo assim, deve haver um processo de implantação).
Eu realmente não gosto de fazer regras duras e rápidas como essa, porque as coisas mudam com o tempo, seja por necessidade ou por mais experiência. É por isso que eu gosto de “diretrizes".
Mas no momento em que escrevo, essas são as coisas que vejo acontecendo.
Ambientes de provisionamento
Nos últimos anos, progredimos muito na rapidez com que podemos provisionar nossos sistemas para que todos se espelhem (ou geralmente sim). Isso inclui nossas caixas de desenvolvimento, como nossas máquinas locais espelham a preparação e como a preparação espelha a produção.
Provisionando um novo ambiente, mais ou menos. Role com isso.
Isto é, se “funcionar na minha máquina” deve ser verdade. Não é uma desculpa para não ser capaz de reproduzir um bug.
E quando é verdade, é provável que seja verdade nas máquinas de outros, na encenação e na produção. E isso é legal, certo? Quer dizer, nós montamos nossas caixas, implantamos nossos scripts, ou fazemos o que fazemos e então temos a configuração de que precisamos.
Então, o que significa provisionar ambientes? Depende de qual ambiente você está se referindo.
O que isso realmente parece?
Se você estiver trabalhando no WordPress, o que eu suponho que esteja se estiver lendo isso, supõe que você esteja executando um servidor web, um banco de dados e PHP no mínimo.
Um ambiente de desenvolvimento pode ter a seguinte aparência:
- Apache de Nginx ,
- MySQL que é o mais comum,
- Pelo menos PHP 5.2.4 (com PHP 7.1 recomendado),
- Ou algo comparável.
Você também pode estar usando algo como Laravel Valet ou algo como VVV. Tudo depende da natureza do seu trabalho.
Além disso, dependendo da natureza do seu negócio, você pode ter um IDE atribuído a você junto com vários arquivos de configuração para impor determinadas regras.
E o Resto dos Ambientes?
Como sempre:
- desenvolvimento refere-se à configuração em sua máquina local,
- encenação refere-se à área na qual você e as partes interessadas podem testar,
- e a produção é onde o aplicativo reside.
Mas isso também parece diferente dependendo de onde você trabalha, como seu trabalho está organizado e assim por diante. Não é tanto sobre como é usado – é sobre como é usado.
Encenação
Isso geralmente será provisionado em um servidor (ou grupo de servidores, dependendo do tamanho do projeto) no qual você pode implantar seu código mais recente para teste. Ele pode incluir funcionalidade parcial, dados de teste e apenas um subconjunto de informações da produção (se você optar por extrair essas informações, ou seja, o banco de dados, do ambiente de produção).
Isso dá a você e às outras partes interessadas a capacidade de revisar o que está acontecendo e como funcionará na produção sem realmente ter que se preocupar em destruir qualquer coisa sensível.
O código geralmente é implantado de uma ramificação, geralmente mestre, do seu repositório Git (se é isso que você está usando). E ferramentas como DeployBot, CircleCI, Travis CI, GrumPHP, Behat, etc. também são usadas para avaliar a qualidade do código, executar qualquer teste automatizado e, finalmente, implantar o código.
No final, cada ambiente será provisionado de forma que possa ser rapidamente espelhado em máquinas locais, servidores de teste e servidores de produção. Além disso, deve ser fácil enviar e extrair dados entre eles para facilitar o trabalho com os dados.
Produção
Finalmente, a produção tem tudo a ver com o projeto em funcionamento real; Isso significa que o servidor, o aplicativo e o banco de dados são executados em conjunto e estão sendo usados pelos usuários.
Isso também significa que o código está em um local estável. Provavelmente existem mecanismos de registro em vigor que notificarão a equipe de desenvolvimento sobre quaisquer problemas. Nenhuma alteração de código deve ocorrer neste ambiente sem que ele passe pelo controle de qualidade ou teste primeiro.
E os processos em vigor?
Ok, digamos que você esteja trabalhando com uma configuração tradicional, por falta de um termo melhor, em que todas as suas implantações sejam feitas via S/FTP em um ambiente de produção (ou mesmo de teste). Dessa forma, os usuários podem baixar arquivos, fazer as alterações e enviá-los de volta.
Isso não é bom.
Isso significa que qualquer pessoa com as credenciais pode fazer login, fazer as alterações e ignorar o controle de origem, integração contínua, ferramentas de garantia de qualidade e assim por diante, realizar as alterações que desejar.
Isso prejudica todos os processos implementados. Isso não apenas ignora o procedimento padrão (que está em vigor por um motivo, é claro), mas acaba quebrando o código que um desenvolvedor ou equipe de desenvolvedores tem em suas máquinas principalmente porque o que está em produção não está mais em sincronia com o repositório do código.
Além disso, esse código pode ser distribuído em ramificações que ainda não foram mescladas ou implantadas. Isso nos deixa com uma variedade de situações em que desenvolvedores e clientes quebraram alguma parte do processo de construção e, portanto, todo o projeto.
Quando chega a hora de verificar a produção, ela está fora de sincronia com o desenvolvimento e a preparação, e ninguém sabe por quê. Quando chega a hora de implantar, as alterações são substituídas e os responsáveis perdem o que pensavam que veriam.
O que uma equipe deve fazer?
Não sei se há uma resposta certa para isso, mas quanto mais tempo eu trabalho neste setor, mais acredito que a empresa – ou empresas – responsáveis por construir a solução para o cliente devem ter controle sobre o processo desde o início. para-fim.
- Os designers são responsáveis por gerenciar suas áreas de criação de conceitos, mocks, criação de modelos de demonstração e solicitação de feedback,
- Os gerentes de projeto são responsáveis pela comunicação com os departamentos,
- Os desenvolvedores são responsáveis por implementar a solução e unir o trabalho dos designers com o back-end funcional,
- O cliente é responsável por revisar as alterações, fornecer feedback e fornecer qualquer outra informação necessária para concluir a tarefa.
Isso significa que quando se trata de configurar o domínio, a hospedagem, os ambientes, o controle de versão, o processo de compilação e a integração contínua, e tudo mais que deixei de mencionar, cabe diretamente à equipe de desenvolvimento.
Fique nas trincheiras, fique no alvo (mas esteja atento às pessoas ao seu redor).
Simplificando, essas não são responsabilidades do cliente nem deveriam ser. Os limites de responsabilidade devem ser definidos, mantidos e respeitados em todas as equipes – não apenas desenvolvedores e clientes ou clientes e designers ou designers e desenvolvedores e assim por diante.
Qual é o próximo?
No próximo post, falarei sobre as responsabilidades que os desenvolvedores (e outras partes interessadas) têm na manutenção de ambientes para o código.
Ou seja, quem deve ser responsável pelo quê e quem tem acesso para ler e escrever quais dados e como isso pode impactar no resultado final do projeto.