Guardrails do projeto: escrevendo para produção

Nos últimos artigos, falei sobre algumas coisas (salvo para realmente escrever para produção) que ajudam a executar um projeto bem-sucedido:

1. Os perigos do ” design por comitê ",
2. Considerações para provisionar um ambiente.

A última coisa que quero abordar sobre o aprendizado que experimentei até agora é sobre manter as chaves proverbiais do reino da escrita para a produção e por que isso importa.

Escrevendo para Produção

A ideia de escrever para produção pode parecer o guardrail mais dogmático dos mencionados, porque geralmente é bom para quem está construindo a solução e conhece os meandros de como está funcionando.

As outras partes interessadas provavelmente não (mas se o fizerem e a equipe de desenvolvimento estiver bem com os outros usando o controle de versão para lidar com isso, vá em frente).

Quem tem permissão para administrar essas coisas, realmente?

Lembre-se, porém, como mencionado anteriormente nesta série, a maneira como estamos implantando nossos projetos mudou agora, de modo que geralmente temos implantação contínua e integração contínua.

E muitas vezes, esses serviços são conectados a um repositório de código-fonte, como o GitHub, e um sistema de mensagens (que, por sua vez, pode ser conectado ao Slack, o que acho útil).

Para que as pessoas da equipe estejam cientes do que foi implantado e quando e saibam como obter o código (que é do repositório, não do download via S/FTP), se necessário.

Quando um hotfix é necessário, ainda deve haver um procedimento em vigor. Talvez alguém esteja de plantão e haja um processo pelo qual ramificação, mesclagem, marcação e controle de versão semântica sejam usados.

Independentemente disso, não se trata tanto de como o processo funciona; é que está no lugar e que é seguido.

Claro, essas coisas não são postas em prática para tornar o desenvolvimento mais complicado (embora eu entenda como isso pode parecer). É pelo contrário. É por vários motivos:

• para manter a implantação contínua, você sabe, contínua,
• ter testes integrados,
• para medir continuamente os padrões de codificação ou a qualidade do código,
• para evitar a codificação de cowboy,
• e mais.

Não se trata tanto de manter outras pessoas de fora, mas se for responsabilidade dos desenvolvedores empurrar o código, então alguém deveria realmente ter acesso de escrita ao servidor?

E essa é a linha de fundo: se você está trabalhando em uma equipe onde os processos que você tem podem minar completamente o trabalho que você está fazendo, afinal, qual é o propósito do processo?

Porque a qualquer momento pode aparecer outra pessoa e isso desconsiderar tudo o que você fez. Você é então, no mínimo:

• preso em ter que puxar suas alterações provavelmente via S/FTP,
• compará-lo usando uma ferramenta de comparação com uma ramificação em que alguém está trabalhando,
• implementar as mudanças (vamos descobrir por que elas foram feitas),
• e, em seguida, voltar a trabalhar nos requisitos.

Parece agitado quando você coloca assim, mas é exatamente o que acontece.

O take-away

Então, qual é o propósito dos últimos posts? Se eu tivesse que resumir da forma mais sucinta possível, seria:

Quando se trata de um projeto, conheça suas responsabilidades e não saia delas. Caso contrário, você corre o risco de descarrilar a coisa toda.

Isso vale para desenvolvedores, designers, clientes, profissionais de marketing, gerentes de projeto, etc. Como as funções são designadas, não sei muito (quer dizer, geralmente fica claro quem deve ser quem nas funções acima), mas quero dizer em termos de quem é a pessoa real – o proprietário do projeto – para todo o projeto.

Não seja assim.

E dependendo de como tudo isso acontece, o projeto pode ser um conjunto relativamente simples de trabalho do dia-a-dia.

Tanto quanto possível, não queremos aproveitar o que estamos fazendo