Gerência de Configuração e Mudanças (GCM)
Introdução
A disciplina Gerenciamento de Configuração e Mudanças tem como finalidade introduzir o estudante do ensino técnico de nível médio aos fundamentos, conceitos e práticas essenciais para o controle e a organização de artefatos em projetos de software. Em ambientes computacionais reais, sistemas estão em constante evolução: arquivos são modificados, versões são atualizadas, correções são aplicadas e novas funcionalidades são incorporadas. Nesse contexto, a ausência de métodos formais para controlar essas mudanças pode resultar em perda de informações, inconsistências, retrabalho e falhas graves de qualidade. A gerência de configuração surge, portanto, como um conjunto estruturado de atividades que garante rastreabilidade, organização e confiabilidade ao processo de desenvolvimento de software, conforme amplamente discutido por Pressman (2011) e Sommerville (2011).
Ao longo da disciplina, o estudante será conduzido a compreender a atividade de gerência de configuração como parte integrante da engenharia de software, envolvendo a identificação de itens de configuração, o registro de seus atributos, o armazenamento controlado, o controle sistemático de mudanças, o acompanhamento por meio de relatórios de status e o gerenciamento de versões e linhas de base (baselines). Esses conceitos, embora formalizados na literatura clássica da área, são apresentados de maneira progressiva e contextualizada, respeitando o nível técnico do curso e enfatizando a aplicação prática, conforme defendido por Molinari (2007), ao tratar da gerência de configuração como uma prática operacional indispensável, e não apenas como um procedimento documental.
A carga horária total de 120 horas-aula, distribuída entre atividades teóricas (40 h/a) e atividades práticas (80 h/a), reflete a natureza eminentemente aplicada da disciplina. O planejamento prioriza o aprendizado ativo em laboratório, permitindo que o estudante vivencie situações reais de controle de versões, organização de repositórios e gestão de mudanças, ao mesmo tempo em que constrói uma base conceitual sólida. Além disso, a disciplina estabelece uma ponte direta com práticas contemporâneas de DevOps e integração contínua, evidenciando como a gerência de configuração sustenta a automação, a colaboração em equipe e a entrega confiável de software, aspectos centrais no cenário atual da tecnologia da informação (SATO, 2013; HUMBLE; FARLEY, 2014).
Por fim, esta disciplina busca desenvolver no estudante não apenas competências técnicas, mas também uma postura profissional baseada em disciplina, organização e responsabilidade sobre o próprio trabalho, características essenciais para sua atuação futura no mercado de tecnologia. Ao compreender e aplicar os princípios da gerência de configuração e mudanças, o aluno estará mais preparado para integrar equipes de desenvolvimento, compreender processos industriais de software e lidar de forma consciente com a complexidade inerente à evolução de sistemas computacionais.
1. Conceito de Configuração em Sistemas de Software
A configuração de software refere-se às características físicas e funcionais de um software, conforme especificadas na documentação técnica ou encontradas no produto final. Essencialmente, é o conjunto de todos os documentos, programas, itens de dados e componentes de suporte que compõem o software.
Em termos práticos, a configuração de software é toda a informação gerada durante o processo de desenvolvimento, incluindo:
- Programas de computador (código-fonte e executáveis).
- Documentos que descrevem os programas, procedimentos ou regras de negócio (documentação técnica e do usuário final).
- Estruturas de dados, sejam internas aos programas ou externas a eles.
A disciplina de Gerência de Configuração e mudanças (GCM) é o processo de padronizar essas configurações de recursos e manter a consistência dos componentes do aplicativo e do servidor ao longo do tempo.
2. Problemas Clássicos Sem Controle de Configuração
Quando um software é desenvolvido sem o devido controle de configuração, a evolução do projeto pode levar rapidamente ao caos.
A Primeira Lei da Engenharia de Sistemas afirma que, independentemente do estágio do ciclo de vida, o sistema sempre se modificará, e o desejo de modificá-lo persistirá. Sem controle adequado, ocorrem problemas graves:
- Aumento de Risco e Erros: Introduzir defeitos torna-se mais provável quando as alterações são feitas sem análise prévia, registro formal ou comunicação à equipe.
- Atrasos e Custos: A falta de controle pode levar a atrasos nas entregas, aumento de custos e retrabalho.
- Inconsistência no Ambiente (“Configuration Drift”): Alterações manuais na configuração dos ambientes (como digitar diretamente em um servidor) podem levar a erros de digitação ou documentação desatualizada. Ambientes diferentes podem começar a divergir em suas configurações, tornando a depuração complexa.
Exemplos de Falhas Clássicas:
- Problemas de Integração por Documentação Obsoleta: Um projeto que envolvia subsistemas separados falhou na integração final porque uma das equipes estava usando um documento de especificação funcional desatualizado há seis meses.
- Falha de Produção por Configuração Manual: Um engenheiro de deploy se esqueceu de atualizar um arquivo de configuração com a URL correta do banco de dados ao implantar em produção. O erro só foi detectado pelos usuários no dia seguinte, quando o sistema utilizava o banco de dados errado.
3. Terminologia Fundamental
A Gerência de Configuração possui conceitos essenciais para garantir que o desenvolvimento do software seja previsível e controlável:
| Termo | Descrição |
| Gerência de Configuração de Software (GCS) | Disciplina que garante a integridade do software, gerenciando sua evolução e controlando as mudanças através do ciclo de vida. |
| Item de Configuração (IC/ICS) | Qualquer elemento do produto de software (código, documento, dados, etc.) que é identificado, único e gerenciado como uma unidade. |
| Baseline (Configuração-Base) | Um conjunto de ICs que foi formalmente revisado e aprovado, marcando um estágio de desenvolvimento. Após o estabelecimento de uma baseline, quaisquer alterações só podem ser feitas por meio de um processo formal de controle. |
| Repositório | Local (base de dados) onde os ICs são armazenados e controlados, mantendo-se o histórico de versões e metadados (quem alterou, quando e por quê). |
| Controle de Versão | Procedimentos e ferramentas para gerenciar as diferentes versões dos ICs criados, registrando o histórico de todas as alterações. |
| Controle de Mudança | Processo formal que combina procedimentos humanos e ferramentas para controlar todas as alterações propostas, desde a solicitação inicial até a implementação e aprovação. |
| Check-in / Check-out | Processo de cópia e aprovação de ICs do repositório para a área de trabalho do desenvolvedor (check-out) e vice-versa (check-in). |
4. Evolução Histórica da Gerência de Configuração
A Gerência de Configuração de Software (GCS) evoluiu de uma disciplina estritamente militar para uma prática essencial em todas as indústrias de software:
- Anos 50: A Gerência de Configuração (GC) nasce nos Estados Unidos, impulsionada pelo Departamento de Defesa para gerenciar projetos complexos, como a produção de aviões de guerra e naves espaciais.
- Anos 60 e 70: Surge a Gerência de Configuração de Software (GCS), mas o foco principal permanece em aplicações militares e aeroespaciais.
- Anos 80 e 90: O foco muda do setor militar para organizações civis. Surgem as primeiras normas e padrões internacionais de qualidade de software, como a ISO e o IEEE, que assimilam as práticas de GCS.
- Sistemas de Versão Precursores: Surgem ferramentas de controle de versão, como o CVS (Concurrent Versions System), que foi amplamente utilizado por ser um dos primeiros sistemas abertos e facilitar a colaboração.
- Anos 2000 em diante: Surgem os Sistemas de Controle de Versão Distribuídos (DVCS), como Git e Mercurial, que são mais rápidos e oferecem novas topologias de trabalho (como o trabalho offline e branching facilitado).
5. Importância no Contexto Industrial
A GCS é crucial para o sucesso de qualquer projeto de software por vários motivos, sendo um elemento central na garantia da qualidade e na eficiência operacional:
- Qualidade e Conformidade: A GCS é um requisito indispensável para obter certificações de qualidade de processo reconhecidas internacionalmente, como o CMM/CMMI Nível 2 e o MPS-BR Nível F.
- Integridade e Rastreabilidade: A GCS mantém a integridade dos produtos de trabalho ao longo do ciclo de vida. Ela garante que as modificações sejam rastreadas e controladas de forma sistemática.
- Eficiência Operacional: Permite que as empresas padronizem as configurações de recursos, o que leva à escalabilidade, eliminando a necessidade de configurar manualmente cada servidor e reduzindo erros. Isso minimiza o esforço humano necessário para manter e evoluir o sistema.
- Suporte a Mudanças: Em vez de impedir alterações (o que é inevitável), a GCS fornece subsídios para gerenciá-las de forma eficaz, garantindo que as modificações ocorram de maneira controlada.
Abordagem
O foco do nosso curso será a prática necessária para o mínimo de administração de uma softhouse que precisa de um DevOps. O que não quer dizer que a teoria não seja importante para dominar completamente esse assunto.
DevOps Pipeline
A imagem representa o ciclo contínuo de DevOps, estruturado como um infinito (∞). A ideia central é simples e profunda: desenvolvimento e operações não são fases isoladas, mas partes de um fluxo permanente de melhoria.
Vamos percorrer cada etapa de forma técnica e didática.
Visão Geral do Ciclo
O lado esquerdo (Dev) concentra as atividades de criação do software.
O lado direito (Ops) concentra as atividades de execução e sustentação em produção.
O formato infinito indica:
-
Não há fim definitivo.
-
Cada ciclo gera aprendizado.
-
O monitoramento retroalimenta o planejamento.
Lado Dev
1.Planejar (Plan)
Aqui nasce o software.
Envolve:
- Levantamento de requisitos
- Definição de backlog
- Modelagem técnica
- Planejamento de sprints
- Definição de arquitetura
Ferramentas típicas:
- Jira, Azure Boards, Trello
- Documentação versionada
- Roadmaps técnicos
Do ponto de vista de Gerência de Configuração, aqui já começa o controle:
- Definição dos primeiros itens de configuração
- Versionamento de documentos
- Estabelecimento de linha-base inicial
2.Codificar (Code)
Transformação dos requisitos em código-fonte.
Envolve:
- Desenvolvimento
- Controle de versão (Git)
- Padrões de codificação
- Branching strategy
Aqui entra fortemente:
- Controle de versão
- Registro de alterações (commits)
- Rastreabilidade de mudanças
Sem versionamento, não existe DevOps — existe caos.
3.Testar (Test)
Validação técnica.
Tipos de teste comuns:
- Testes unitários
- Testes de integração
- Testes automatizados
- Testes de regressão
No modelo DevOps, testes devem ser:
- Automatizados
- Integrados ao pipeline CI
- Executados a cada commit
Aqui o objetivo é reduzir risco antes da publicação.
4.Criar (Build)
Transformar código em artefato executável.
Exemplos:
- Gerar .jar, .war
- Criar imagem Docker
- Gerar pacote .deb/.rpm
- Build de aplicação web
Ferramentas comuns:
- Maven, Gradle
- npm
- Docker
- Jenkins
Esse momento consolida uma versão formal do sistema.
Pode ser considerada uma linha-base técnica.
Lado Ops
5.Publicar (Release / Deploy)
Disponibilizar o artefato no ambiente alvo.
Pode envolver:
- Deploy manual
- Deploy automatizado
- CI/CD pipelines
- Blue-Green deployment
- Canary release
Aqui entra o conceito de:
- Entrega Contínua (Continuous Delivery)
- Implantação Contínua (Continuous Deployment)
Gerência de configuração atua garantindo:
- Versão correta
- Ambiente correto
- Artefato íntegro
6.Implementar (Implement)
Na figura, “implementar” representa a ativação efetiva no ambiente operacional.
Inclui:
- Provisionamento de infraestrutura
- Configuração de servidores
- Infraestrutura como Código (IaC)
- Configuração de containers
Ferramentas típicas:
- Terraform
- Ansible
- Kubernetes
- Docker
Aqui a configuração deixa de ser apenas software e passa a incluir infraestrutura.
7.Operar (Operate)
O sistema está em produção.
Atividades:
- Administração do ambiente
- Correções emergenciais
- Gestão de incidentes
- Aplicação de patches
Neste ponto, o foco é:
- Disponibilidade
- Desempenho
- Segurança
DevOps reduz a separação entre quem desenvolve e quem opera.
8.Monitorar (Monitor)
O ciclo fecha aqui — e reinicia.
Monitoramento envolve:
- Logs
- Métricas
- Telemetria
- Observabilidade
Ferramentas comuns:
- Prometheus
- Grafana
- ELK Stack
- Azure Monitor
O monitoramento gera:
- Feedback técnico
- Dados reais de uso
- Evidências de falhas
- Insights para melhorias
Essas informações retornam para o Planejar, reiniciando o ciclo.
O que a imagem ensina conceitualmente?
- Dev e Ops são interdependentes.
- O processo é contínuo.
- Automação é o elo invisível que conecta tudo.
- Monitoramento é tão importante quanto codificação.
- Gerência de Configuração permeia todo o ciclo.
Conexão com Gerenciamento de Configuração
Observe algo fundamental:
Cada etapa produz ou modifica itens de configuração:
- Código
- Scripts
- Infraestrutura
- Documentação
- Artefatos compilados
- Ambientes
Sem:
- Controle de versão
- Baselines
- Controle de mudanças
- Rastreabilidade
O ciclo DevOps se torna instável.
DevOps não elimina Gerência de Configuração.
Ele a amplia para o ambiente operacional.
Síntese Conceitual
DevOps é menos uma ferramenta e mais um modelo de fluxo contínuo de valor.
Ele reduz:
- Tempo entre ideia e produção
- Risco de erro humano
- Conflitos entre equipes
E aumenta:
- Automatização
- Transparência
- Confiabilidade
- Velocidade de entrega
A origem da cultura DevOps
Uma análise histórica e conceitual
DevOps não surgiu como uma tecnologia específica. Surgiu como resposta organizacional a um problema estrutural na engenharia de software: a separação rígida entre quem desenvolve e quem opera sistemas.
1.O contexto anterior (1990–2005)
Durante as décadas de 1990 e início dos anos 2000, predominava um modelo organizacional fortemente compartimentalizado:
- Equipe de Desenvolvimento (Dev) → focada em entregar funcionalidades.
- Equipe de Operações (Ops) → responsável por estabilidade e infraestrutura.
Esse modelo era herdeiro do paradigma industrial e do modelo sequencial de engenharia (influência do modelo cascata).
O resultado típico era:
- Conflito de objetivos
- Entregas lentas
- Falta de responsabilidade compartilhada
- Ambientes de produção instáveis
Nesse período, já existia o conceito formal de Gerência de Configuração de Software, descrito em obras como a de Roger S. Pressman em Engenharia de Software (7ª ed., 2011) e também em Ian Sommerville (9ª ed., 2011).
Esses autores tratavam de versionamento, baselines e controle de mudanças — mas ainda dentro de uma lógica relativamente compartimentalizada.
2.A influência do Agile (2001)
Em 2001, um grupo de desenvolvedores publica o Manifesto Ágil, nos Estados Unidos, em Snowbird, Utah.
O movimento ágil defendia:
- Entregas frequentes
- Colaboração próxima com o cliente
- Resposta rápida a mudanças
Contudo, o Agile focava principalmente no processo de desenvolvimento, não na operação em produção.
Começou então a surgir um descompasso:
Desenvolvedores entregavam mais rápido, mas operações não acompanhava essa velocidade. Esse atrito preparou o terreno para DevOps.
3.A crise das implantações (2005–2008)
Entre 2005 e 2008, grandes empresas de tecnologia enfrentavam um problema recorrente:
“Funciona na minha máquina, mas quebra em produção.”
A expansão de sistemas web, virtualização e infraestrutura distribuída aumentou a complexidade operacional.
Nesse contexto, surgiram práticas como:
- Infraestrutura como Código (IaC)
- Automação de builds
- Automação de deploy
Ferramentas como Puppet e Chef começaram a ganhar espaço.
4.O nascimento formal do termo (2009)
O termo DevOps surge em 2009, na Bélgica.
O responsável por popularizar o conceito foi Patrick Debois, consultor belga de TI.
Ele organizou o primeiro evento chamado:
DevOpsDays — Ghent, Bélgica, 2009.
O evento foi inspirado por uma apresentação de John Allspaw e Paul Hammond na conferência Velocity 2009 (EUA), onde mostraram como a empresa Flickr integrava desenvolvimento e operações.
Ali nasce a ideia central:
Desenvolvimento e operações devem colaborar continuamente.
5.Consolidação intelectual (2010–2016)
A cultura DevOps ganha base teórica e difusão global com obras como:
-
The Phoenix Project — Gene Kim, Kevin Behr, George Spafford (2013)
→ Apresenta DevOps como narrativa organizacional. -
The DevOps Handbook — Gene Kim, Jez Humble, Patrick Debois, John Willis (2016)
→ Estrutura práticas e princípios. -
Jez Humble e David Farley em Continuous Delivery (2010)
→ Fundamentam automação de build e deploy.
Nesse período, consolida-se o conceito das Três Maneiras (Three Ways) do DevOps:
- Fluxo contínuo
- Feedback rápido
- Aprendizado contínuo
6.Base conceitual profunda
DevOps não surge do nada. Ele herda princípios de:
- Lean Manufacturing (Toyota Production System)
- Teoria das restrições (Goldratt)
- Gerência de Configuração
- Engenharia de Confiabilidade
A influência do pensamento Lean é particularmente forte:
Reduzir desperdício, aumentar fluxo e melhorar continuamente.
7.Situação geográfica e cultural
DevOps nasce no contexto:
- Europa (Bélgica) → formulação inicial
- Estados Unidos → expansão e consolidação
- Empresas web de alta escala (Flickr, Amazon, Netflix)
É um fenômeno cultural típico da economia digital:
- Alta complexidade
- Necessidade de deploy frequente
- Ambientes distribuídos
8.O que DevOps realmente é
DevOps não é:
- Uma ferramenta
- Um software
- Um framework fechado
É:
- Uma cultura organizacional
- Um conjunto de práticas técnicas
- Um modelo de integração sociotécnica
Ele transforma:
- Separação funcional → responsabilidade compartilhada
- Entrega esporádica → entrega contínua
- Operação reativa → monitoramento ativo
9.Linha do tempo resumida
| Período | Evento |
| 1990–2005 | Separação forte Dev/Ops |
| 2001 | Manifesto Ágil |
| 2005–2008 | Crise de deploy e complexidade |
| 2009 | DevOpsDays (Bélgica) |
| 2013 | The Phoenix Project |
| 2016 | The DevOps Handbook |
Conclusão acadêmica
DevOps emerge como resposta histórica à fratura organizacional entre desenvolvimento e operações, catalisada pela necessidade de entrega rápida em ambientes de alta complexidade tecnológica.
Ele representa uma evolução da Gerência de Configuração clássica, expandindo-a para o ciclo completo de vida do software.
Em termos epistemológicos, DevOps é uma integração entre:
- Engenharia de Software
- Teoria organizacional
- Automação tecnológica
- Pensamento Lean
E continua evoluindo…
O que os técnicos fazem em cada etapa do ciclo DevOps
Uma análise técnica, operacional e ferramental
DevOps não é apenas um fluxo conceitual. Ele se materializa em atividades técnicas concretas, executadas por profissionais com responsabilidades bem definidas. Abaixo, descrevo cada etapa do ciclo com:
- Objetivo técnico
- Responsabilidades dos profissionais
- Softwares mais utilizados no mercado
1.Planejar (Plan)
Objetivo
Definir requisitos, priorizar demandas e organizar o fluxo de trabalho.
O que os técnicos fazem
- Levantamento e refinamento de requisitos técnicos
- Modelagem arquitetural
- Definição de backlog
- Planejamento de sprints
- Definição de critérios de aceite
- Identificação inicial de itens de configuração
Aqui ocorre a primeira formalização da rastreabilidade.
Softwares mais utilizados
- Jira (Atlassian)
- Azure DevOps Boards
- Trello
- GitHub Projects
- Confluence (documentação)
2.Codificar (Code)
Objetivo
Produzir código versionado, rastreável e colaborativo.
O que os técnicos fazem
- Implementação de funcionalidades
- Criação de branches
- Commits estruturados
- Code review
- Merge requests
- Aplicação de padrões de codificação
Nesta fase o controle de versão é obrigatório.
Softwares mais utilizados
- Git (ferramenta central)
- GitHub
- GitLab
- Bitbucket
- Visual Studio Code
- IntelliJ IDEA
3.Testar (Test)
Objetivo
Validar funcionalidade, segurança e estabilidade.
O que os técnicos fazem
- Criar testes unitários
- Implementar testes automatizados
- Executar testes de integração
- Testes de regressão
- Testes de segurança (SAST/DAST)
Testes devem ser integrados ao pipeline automatizado.
Softwares mais utilizados
- JUnit (Java)
- PyTest (Python)
- NUnit (.NET)
- Selenium (testes web)
- Cypress
- SonarQube (análise de qualidade)
4.Criar (Build)
Objetivo
Transformar código em artefato executável e versionado.
O que os técnicos fazem
- Compilação
- Empacotamento
- Geração de imagens Docker
- Versionamento de artefatos
- Assinatura digital (quando aplicável)
É aqui que nasce a linha-base executável.
Softwares mais utilizados
- Maven
- Gradle
- npm
- Docker
- Jenkins (orquestra build)
- GitHub Actions
- GitLab CI
5.Publicar (Release / Deploy)
Objetivo
Disponibilizar o artefato em ambiente controlado.
O que os técnicos fazem
- Configuração de pipeline CI/CD
- Deploy automatizado
- Versionamento de releases
- Estratégias Blue-Green ou Canary
- Gerenciamento de rollback
Aqui ocorre forte integração entre desenvolvimento e operações.
Softwares mais utilizados
- Jenkins
- GitHub Actions
- GitLab CI/CD
- Azure DevOps Pipelines
- ArgoCD
- Octopus Deploy
6.Implementar (Infrastructure & Configuration)
Objetivo
Provisionar e configurar infraestrutura de forma automatizada.
O que os técnicos fazem
- Provisionamento de servidores
- Configuração de rede
- Infraestrutura como Código (IaC)
- Gerenciamento de containers
- Configuração de clusters
A infraestrutura torna-se código versionado.
Softwares mais utilizados
- Terraform
- Ansible
- Puppet
- Chef
- Kubernetes
- Docker
- Helm
7.Operar (Operate)
Objetivo
Garantir disponibilidade e confiabilidade do sistema em produção.
O que os técnicos fazem
- Monitoramento de uptime
- Correção de incidentes
- Gestão de capacidade
- Aplicação de patches
- Gerenciamento de backups
- Gestão de segurança operacional
Aqui entram conceitos de SRE (Site Reliability Engineering).
Softwares mais utilizados
- Kubernetes
- Linux Server
- AWS / Azure / Google Cloud
- Nginx
- Apache
- Zabbix
8.Monitorar (Monitor)
Objetivo
Coletar dados operacionais para retroalimentar o ciclo.
O que os técnicos fazem
- Monitoramento de métricas
- Coleta de logs
- Observabilidade
- Alertas automáticos
- Análise de desempenho
- Análise de incidentes
Sem monitoramento, não há melhoria contínua.
Softwares mais utilizados
- Prometheus
- Grafana
- ELK Stack (Elasticsearch, Logstash, Kibana)
- Datadog
- New Relic
- Azure Monitor
- CloudWatch
Integração entre as etapas
É fundamental entender que:
- Todas as ferramentas são integráveis.
- O pipeline CI/CD conecta Code → Test → Build → Deploy.
- Monitoramento retroalimenta o Planejamento.
Perspectiva Acadêmica
DevOps pode ser compreendido como:
- Integração sociotécnica
- Modelo de fluxo contínuo
- Sistema complexo adaptativo
- Evolução da Gerência de Configuração
Cada etapa produz e modifica itens de configuração:
- Código
- Scripts
- Artefatos
- Infraestrutura
- Ambientes
A disciplina de Gerenciamento de Configuração garante:
- Rastreabilidade
- Controle de mudanças
- Baselines
- Integridade sistêmica
Síntese Estruturada
| Etapa | Foco Técnico | Ferramentas Principais |
| Planejar | Organização do trabalho | Jira, Azure Boards |
| Codificar | Desenvolvimento versionado | Git, GitHub |
| Testar | Validação automatizada | JUnit, Selenium |
| Criar | Geração de artefatos | Maven, Docker |
| Publicar | Deploy automatizado | Jenkins, GitLab CI |
| Implementar | Infraestrutura como código | Terraform, Kubernetes |
| Operar | Administração em produção | Linux, Cloud |
| Monitorar | Observabilidade | Prometheus, Grafana |
Conclusão
Os técnicos em DevOps não são apenas programadores ou administradores de sistemas. São profissionais que:
- Automatizam processos
- Integram ferramentas
- Garantem rastreabilidade
- Monitoram continuamente
- Respondem rapidamente a mudanças
DevOps transforma o ciclo de vida do software em um fluxo contínuo e mensurável de entrega de valor.
Fim da Aula 01