Questão de Engenharia de Software — DevOps, IaC, Integração Contínua e Entrega Contínua — VUNESP 2025

Controle de versão no contexto de DevOps

Gabarito: letra D. No contexto de DevOps, o controle de versão é uma prática fundamental que se aplica a todos os tipos de artefatos — código-fonte, scripts, arquivos de configuração, infraestrutura como código (IaC), documentação, entre outros — e não se restringe a uma única equipe ou a um único repositório. A alternativa D está correta ao afirmar que é justificável utilizar vários repositórios e sistemas de versionamento simultaneamente para diferentes tipos de arquivos e artefatos, mesmo que isso exija conhecimento de diferentes ferramentas.

O controle de versão é o alicerce de qualquer prática moderna de desenvolvimento e operações. Ele permite rastrear mudanças, colaborar de forma eficiente, reverter alterações indesejadas e manter um histórico completo do que foi feito. No DevOps, essa prática vai além do código-fonte: ela se estende a scripts de automação, arquivos de configuração, definições de infraestrutura (IaC), pipelines de CI/CD, documentação e até mesmo a dados e artefatos de projeto. A ideia central é que tudo o que define o sistema deve ser versionado, para que o ambiente possa ser reproduzido de forma consistente e auditável.

A prática de versionar múltiplos tipos de artefatos em repositórios distintos é comum e recomendada. Por exemplo, uma equipe pode manter o código-fonte da aplicação em um repositório Git, os scripts de infraestrutura (Terraform, Ansible) em outro, e os pipelines de CI/CD (Jenkinsfile, GitLab CI) em um terceiro. Cada repositório pode ter seu próprio ciclo de vida, permissões de acesso e estratégia de branching, adaptados à natureza do artefato. Isso não significa fragmentação desnecessária, mas sim organização e especialização: cada tipo de artefato é versionado com a ferramenta mais adequada e com políticas específicas.

A alternativa D captura exatamente essa realidade: é justificável e até recomendado utilizar vários repositórios e sistemas de versionamento simultaneamente para diferentes tipos de arquivos, artefatos de projeto, objetos e serviços. Isso pode exigir que a equipe conheça diferentes ferramentas (Git, SVN, Mercurial, etc.), mas o benefício de ter cada artefato versionado de forma adequada supera o custo de aprendizado. A banca explora aqui a ideia de que o controle de versão não é uma prática monolítica, mas sim flexível e adaptável às necessidades de cada contexto.

A pegadinha central desta questão é a tentação de associar o controle de versão apenas ao código-fonte e à equipe de desenvolvimento. As alternativas incorretas exploram exatamente essa visão limitada: a letra A sugere que scripts e configurações de IaC não devem ser versionados por segurança (o oposto do que a prática recomenda), a letra B restringe o uso a equipes distribuídas geograficamente, a letra C limita a prática a equipes grandes, e a letra E exclui a equipe de operações. Todas essas visões contrariam o princípio DevOps de colaboração e automação, onde o versionamento é uma prática universal e inclusiva.

Guarde o critério decisivo: no DevOps, o controle de versão é uma prática universal e inclusiva — aplica-se a todos os artefatos, a todas as equipes e a qualquer tamanho de organização. É exatamente essa universalidade que separa a alternativa correta das incorretas.

Alternativa A — ❌ Incorreta

A alternativa afirma que não se recomenda inserir scripts e arquivos de configuração relacionados à criação automática de infraestrutura em repositórios de controle de versão, por razões de segurança. Isso é exatamente o oposto do que a prática de Infraestrutura como Código (IaC) preconiza. A IaC é uma prática em que a infraestrutura é provisionada e gerenciada usando técnicas de desenvolvimento de código e software, como controle de versão e integração contínua. Os arquivos de configuração devem pertencer à fonte como qualquer outro código-fonte de software. A segurança não é motivo para excluir esses arquivos do versionamento; pelo contrário, versionar permite auditar mudanças, rastrear quem alterou o quê e quando, e reverter alterações problemáticas. A preocupação com segredos (como senhas e chaves) é legítima, mas a solução não é deixar de versionar, e sim usar práticas seguras como variáveis de ambiente, cofres de segredos (vaults) e arquivos de configuração que não contenham informações sensíveis diretamente.

Alternativa B — ❌ Incorreta

A alternativa afirma que o controle de versão é justificado exclusivamente quando a equipe trabalha de forma geograficamente distribuída, e que, estando no mesmo escritório físico, seria mais fácil trabalhar com pastas compartilhadas em um servidor local. Isso é um equívoco. O controle de versão é benéfico independentemente da localização da equipe. Mesmo em um mesmo escritório, o versionamento oferece vantagens como histórico de mudanças, capacidade de reverter alterações, trabalho em branches paralelos, revisão de código e rastreabilidade. Pastas compartilhadas em um servidor local não oferecem essas funcionalidades e podem levar a conflitos de edição, perda de dados e falta de rastreabilidade. A distribuição geográfica é apenas uma das razões para usar controle de versão, não a única nem a exclusiva.

Alternativa C — ❌ Incorreta

A alternativa afirma que o controle de versão é recomendado para equipes grandes, mas pouco recomendado para equipes pequenas, e que em projetos realizados por um único desenvolvedor essa prática não deve ser adotada. Isso é falso. O controle de versão é benéfico para equipes de qualquer tamanho, inclusive para um único desenvolvedor. Mesmo trabalhando sozinho, um desenvolvedor se beneficia do versionamento para manter histórico de mudanças, experimentar em branches, reverter alterações e ter um backup seguro do código. Para equipes pequenas, o versionamento é igualmente importante para organizar o trabalho e evitar conflitos. A recomendação é universal: sempre use controle de versão, independentemente do tamanho da equipe.

Alternativa D — ✅ Correta ⟵ GABARITO

A alternativa afirma que se justifica utilizar vários repositórios e sistemas de versionamento, simultaneamente, para diferentes tipos de arquivos, artefatos de projeto, objetos e serviços, mesmo que isso requeira conhecimentos da equipe em diferentes ferramentas. Isso está correto e reflete a prática recomendada no contexto de DevOps. Diferentes tipos de artefatos podem ter necessidades distintas de versionamento: código-fonte, scripts de infraestrutura, pipelines de CI/CD, documentação, dados, etc. Utilizar repositórios separados para cada tipo permite políticas de acesso, ciclos de vida e estratégias de branching específicas. Embora isso possa exigir conhecimento de múltiplas ferramentas, o benefício de ter cada artefato versionado de forma adequada supera o custo. A alternativa D captura essa flexibilidade e é a única que está alinhada com as práticas modernas de DevOps.

Alternativa E — ❌ Incorreta

A alternativa afirma que o controle de versão é utilizado exclusivamente pela equipe de desenvolvimento, e não pela equipe de operações, já que esta equipe não lida com código-fonte, arquivos de scripts de testes automatizados etc. Isso é um equívoco. No contexto de DevOps, a equipe de operações também lida com artefatos que devem ser versionados, como scripts de automação, arquivos de configuração de infraestrutura (IaC), pipelines de CI/CD e definições de ambientes. A colaboração entre desenvolvimento e operações é um princípio central do DevOps, e o controle de versão é uma ferramenta que une essas equipes, permitindo que ambas trabalhem de forma integrada e rastreável. A alternativa E reforça uma visão de silos, que é exatamente o oposto do que o DevOps preconiza.

Gabarito: letra D