Gerência de Configuração de Itens

Prévia do material em texto

AULA 02
Item de Configuração
Item de configuração é o conceito central ao redor do qual o processo de GC é estruturado.
Diz respeito aos próprios itens que estão sob a guarda direta do processo, ou seja, as entidades que precisam ser protegidas e que justificam a existência do aparato da configuração.
São considerados
· Hardware
· Software
· Documentação
Todos os itens de configuração terão certas informações a serem preenchidas.
Informações -> atributos
Valores de cada atributo -> metadados.
VERSÃO
Itens de configuração apresentam um ciclo de vida que pode começar por:
· Sua aquisição ou desenvolvimento
· Implantação
· Fases intermediárias
· Substituição ou aposentadoria
As fases intermediárias podem ser vistas como estágios, onde o item de configuração será evoluído ou alterado de alguma maneira, garantindo a atualização do item.
Cada variação constitui um novo item.
Chamamos de versão, quando propriamente identificadas.
Linha de base
É necessário um mecanismo que separe as versões estáveis, aptas a uso, das versões inacabadas ou instáveis. 
Só podem ser alteradas se houver autorização formal.
Biblioteca
Bibliotecas são áreas destinadas ao armazenamento de infromações. No âmbito da GC estamos falando de itens de configuração compostos exclusivamente por software(código-fonte, componentes, etc.), ou então por um mix de ambos.
· Biblioteca de desenvolvimento - Para itens de configuração que estão em fase de implementação.
· Bibliotecas de teste - Itens de configuração que estão passando por testes ou por verificações relacionadas a qualidade.
· Bibliotecas de homologação - Para itens de configuração que estão passando por testes dos usuários.
· Bibliotecas de produção - Para itens de configuração que estão prontos para uso no dia a dia.
Procedimentos Gerência de Configuração
GESTÃO O PROCESSO DE GC - Dá subsídio a adoção do processo de GC. Planejamento apropriado para que se obtenha sucesso neste empreendimento.
Entendimento do contexto organizacional.
Cronograma
Metas
Objetivo
Pontos criticos
O que a organização deseja obter do processo
O que a organização deseja abranger com o processo
Qual o nível de suporte ou apoio que a alta administração concederá à adoção do processo
QUais papéis estarão envolvidos na GC
CONTABILIDADE DO STATUS DA CONFIGURAÇÃO - Um dos mais importantes.
Entrega saídas ou resultados relevantes para outros processos organizacionais.
Ligado diretamente com o resultado final.
Designa para cada área o que está errado.
GESTÃO DE ENTREGA E LIBERAÇÃO - Geração e implementação de um item de configuração em um ambiente, interno ou externo à organização, que não seja usado para o propósito de desenvolvimento.
É função do procedimento de Gestão da Entrega e Liberação a devida identificação, documentação, empacotamento e entrega de um produto como um todo, ou ao menos de parte deste produto.
AUDITORIA DA CONFIGURAÇÃO - As auditorias de configuração são peça-chave para que esta conformidade seja aferida, representando uma espécie de exame dos itens de configuração com relação ao nível de aderência deles a estas características.
Como implementar a GC:
· Planejamento - planejar antes de executar. Cronograma. Gestão do processo
· Itens que serão considerados na GC - nível intermediário.
· Criar um repositório para as informações - aplicação, aplicação específica para a área de GC e um banco de dados.
BOAS PRÁTICAS:
GC como uma etapa do ciclo de vida do software.
Estabelecer as baselines de acordo com marcos no projeto. Sem ser as entregas para cliente.
Ambientes especificos para cada área para cada etapa.
AULA 3
Controle de Versão e seus Fundamentos
O controle de versão basicamente se foca em uma coisa: registrar e rastrear as mudanças que ocorrem nestes itens de configuração.
Banco de dados - repositório.
Conceitos habilitadores dos sistemas de controle de versão
· Cópia de trabalho (working copy, sandbox ou checkout): itens de configuração que foram selecionados por um usuário e que agora se encontram bloqueados para edição para aquele usuário, enquanto são realizadas as alterações necessárias. Estas são as cópias locais em que o usuário estará trabalhando.
· Confirmação (Commit): também conhecido como “realizar um commit”, é uma ação de confirmação, sendo uma ação deliberada por parte de um usuário para as mudanças em um item de configuração que ele tenha realizado, enviando-as ao servidor, tornando-as oficiais e disponíveis a outros usuários.
· Grupo de mudanças (changeset): é um novo registro gerado automaticamente no repositório para cada commit realizado. Cada changeset ou grupo de mudanças pode conter inúmeras modificações em um ou mais itens de configuração, e seu tamanho e extensão depende de quão frequentemente os usuários escolhem realizar commits. Por exemplo, um usuário pode escolher realizar commits para cada alteração significativa, o que implica em vários commits em um curto espaço de tempo, como minutos ou horas, ou pode escolher realizar commits para períodos maiores de tempo, incluindo dias ou até semanas.
· Revisão (revision): Número identificador único dado a cada changeset. A idéia dos revisions é facilitar a rastreabilidade das mudanças.
· Etiqueta (tag ou label): Uma revisão que foi congelada, normalmente se tornando “somente-leitura” e que muito provavelmente é candidata a ser liberada para produção.
· Atualização (Update): também conhecido como “realizar uma atualização”, ocorre quando usuários deliberadamente realizam o download de um changeset do repositório, de forma a possuírem a última versão do código fonte ou documentação.
· Diferenciação (diffing): é um mecanismo de visualização das diferenças entre revisões. Facilitando, portanto, a comparação entre versões de um mesmo item de configuração, bem como proporciona conhecimento sobre quem e quando realizou a alteração em questão. A comparação pode ser feita linha a linha para as versões dos itens de configuração, para revisões sequenciais e até mesmo entre duas revisões em qualquer ponto no histórico dos itens de configuração.
· Ramificação (branching): serve para criação de cópias alternativas ou ramos (branches) do código fonte / documentação a ser alterados, permitindo a execução das alterações sem modificação direta do tronco ou código / documentação mestre (master). Branching é importante pois dá subsídio à realização de testes e da consequente estabilização das versões, levando à redução dos riscos resultantes de alterações não-intencionais ou mesmo de alterações planejadas.
· Fusão (merging): serve para unificar ou fundir trechos de alterações ou mesmo alterações completas de autoria de usuários diferentes, em uma única nova versão, a ser combinada com a versão mestre disponível no repositório. Como se pode imaginar, é também o mecanismo usado para reunificar o código de um ou mais ramos ao código mestre, uma vez que exista confiança que estes ramos são estáveis e que não irão causar problemas.
· Conflitos de versão: ocorrem quando dois ou mais usuários alteram o mesmo trecho ou linha do mesmo pedaço de código-fonte ou documentação, seja por engano, seja quando criam ramos diferentes para isso. Normalmente requerem fusão para eliminação do conflito, no entanto é possível que a ferramenta de controle de versão não consiga sozinha determinar a versão válida, requerendo portanto escolha e intervenção manual.
Diferentes Tipos de Controle de Versão
Repositórios são organizados em pastas(ou diretórios) e arquivos. Conforme usuários vão realizando mudanças nas estruturas destas pastas e arquivos, é tarefa do controle de versão manter a rastreabilidade dessas mudanças.
Com o intuito de cumprir esse objetivo, os Sistemas de Controle de versão se organizam de duas maneiras:
Controle de Versão Centralizado
· O sistema de controle de versão irá esperar que o usuário autor das mudanças envie as mudanças realizadas para “registro oficial”. Requer o envio deliberado do changeset pelo usuário-autor, via ações de commit.
· Ocorre quando demais usuários precisam realizaruma atualização.
Arquitetura Client-server. Ações ficam do lado do servidor.
Repositório Central.
Não cria branches.
Este tipo de controle de versão tem a vantagem de que torna relativamente fácil saber quais partes do código-fonte e documentação entram-se bloqueadas para edição.
Controle de Versão Distribuído
Difere da abordagem centralizada já que nesta modalidade, além de um repositório centralizado, cada usuário possuirá sua própria cópia local deste repositório inteiro, formando assim uma espécie de rede de repositórios interconectados. A realização de commits não irá enviar as alterações a outros repositórios e torná-las disponíveis aos demais usuários, pois aqui o commit se limita a confirmar no repositório local as alterações realizadas pelo autor nos itens de configuração que estavam checked-out.
Para que os demais repositórios sejam sincronizados, além das já conhecidas ações de confirmação e atualização, são necessárias ainda mais duas ações adicionais, totalizando quatro ações:
· Ação empurra (push): o autor das alterações, após commit em seu repositório local, empurra as alterações deste repositório local para o repositório centralizado, disponibilizando-a para os demais usuários.
· Ação puxa (pull): os usuários puxam ou realizam o download das atualizações agora disponíveis no repositório central para seus próprios repositórios locais. Somente aí a ação de atualização será executada, fazendo com que os seus checkouts, ou as cópias dos itens de configuração em que estão efetivamente trabalhando reflitam as últimas alterações disponíveis.
Fica claro portanto que no controle de versão distribuído, as operações de confirmação e atualização apenas movem mudanças entre os checkouts e o repositório local, sem afetar nenhum outro repositório. Já as operações do tipo puxa e empurra movem mudanças entre o repositório local e o repositório central, sem afetar os checkouts.
Da mesma forma que no controle centralizado de versão, no controle de versão distribuído também existe potencial para conflitos de versão, ou seja, situações em que dois ou mais usuários realizem alterações em uma mesma linha de código ou documentação.
A ferramenta Git é um bom exemplo de implementação do paradigma distribuído.
Pull request
Copia local
Commit
Push para o repositório central ou uma branch
Boas Práticas no Controle de versão
· Usar mensagens de confirmação que sejam o mais descritivas possível
· Trate cada confirmação de forma atômica
· Evite realizar confirmações de maneira indiscriminada
· Incorpore mudanças de terceiros frequentemente
· Compartilhe suas próprias mudanças frequentemente
· Coordene com seus pares
· Evite confirmar arquivos gerados ou não editáveis
· Invista no conhecimento da funcionalidade de merge
· Habilite notificação por email.
AULA 4
O Controle de Mudança e seus Fundamentos
A GC dispõe do Controle de Mudanças, cujo propósito é de atuar como “porteiro”, ou seja, estar no comando de todos os pedidos de mudança para um produto, bem como de todas as mudanças implementadas.
Para todo e qualquer item de configuração, é preciso que seja possível identificar mudanças em relação aos itens que vierem antes dele.
Qualquer mudança precisa ser rastreável.
O Controle de Mudanças identifica, documenta, aprova ou rejeita e controla mudanças em itens de configuração disponíveis em projetos, operações, etc.
É iniciado por um evento, que nem sempre é formalizado logo em um primeiro momento, podendo ser inicialmente apenas por uma intenção ou desejo por mudança.
Objeto com interação.
Mudança
Solicitação (ou Requisição) de Mudança
Linha de Base (baseline)
Comitê de (Avaliação de) Mudanças
Controle de mudanças usa um volume considerável de automação
Ferramentas: GitLab
AULA 5
Gerenciamento de Construção
Unir os ativos e os itens de configuração.
Está a frente da geração do build.
Build:
Compilação de todos os itens do código fonte
Empacotamento, teste e implementação
Passo de coletar todos os ativos e itens de configuração a serem incluídos em uma construção(build), seja como parte de uma nova implementação, em resposta a mudanças, em preparação para atender a uma liberação, concretizar uma implantação, e ainda por quaisquer outras razões pertinentes.
Em outras palavras, é toda a orquestração da automação necessária para que de fato se gere um produto de software concreto.
As construções são, portanto, a concretização da adição de funcionalidades e / ou modificações requeridas para que se atinjam as performances esperadas em termos de requisitos contratados, sejam esses requisitos funcionais ou não funcionais.
À medida que as aplicações crescem, é impossível ignorar a complexidade aumentada que elas trazem consigo; logo, atividades normais do dia a dia passam a requerer gestão, sendo a construção apenas uma dessas atividades
Gestão das dependências
Plugin
API
Frameworks
Direta - Componente diretamente ligado a outro.
Indireta - Componentes usados pelos componentes utilizados no código-fonte
Beneficios:
· Qualidade - Menor conflito
· Segurança
· Performance
· Direitos de propriedade intelectual
Boas Práticas:
· Processo separado para Construção da Build, pessoas especializadas.
· Planejamento -
· Quais itens serão considerados dentro da construção da Build
· FOrma - Manual, automático
· Ferramentas - Prontas ou precisa criar
· Subtarefas - Específicos de acordo com a forma
· Pessoa responsável para cuidar da área
· Tempo para construir a Build
· Ambiente e a forma como será realizado
· Precisa ter a opção manual caso o automatizado dê problema
· Processo ser iniciado durante o dia
Ferramentas
Maven
Gradle
AULA 6
Gerenciamento de Liberação
Tem por propósito assegurar a distribuição de itens de configuração para fora das fronteiras das atividades de desenvolvimento.
Identificação de todos os itens necessários
Empacotamento dos itens
Entrega direta dos elementos componentes de um produto
Procedimentos de teste podem estar diretamente acoplados aos de liberação
A principal razão das liberações existirem é o de transicionar mudanças para o ambiente operacional.
Precisa passar por um controle antes de liberar novas versões
Liberações baseadas no nível de impacto
· Liberações maiores - Tem como objetivo primário o de entregar novas funcionalidade, são de amplo escopo. Tem como objetivo secundário corrigir problemas, inclusive eliminando soluções temporárias. Versões macro
· Liberações menores - Implementar correções para problemas existentes em uma linha de base ou estado acordado de um item de configuração. Liberações menores não tendem a adicionar funcionalidades.
· Liberações Emergências - Se destinam a implementar mudanças emergencias
Liberações baseadas no nivel de agrupamento
· Lieberação Delta
· Liberações Completas
· Liberações em Pacote
Boas práticas
· Pessoa específica responsável pela liberação
· Definir Ciclo de entrega
· Metodologias Ágeis
· Requisitos do criterio de aceite bem claro
· Infraestrutura de liberação o mais rapidamente possivel.
Aula 7
Integração Contínua
Trata de continuamente fundir ou unificar atualizações no código-fonte por parte de todos os desenvolvedores da equipe, em uma versão considerada a versão principal.
Utilizado em Xtreme Programing
Integrar a maior quantidade possível de vezes o código e disponibilizar no repositório central.
· Repositorio controle de versão - subir alterações feitas no codigo
· Build automatizado
· Testes automatizados
· Integridade - Integração contínua
Vantagens e Desvantagens
VANTAGENS:
· Mudanças menores de código
· Isolamento de falhas
· Confiança nos testes
· Liberações mais rápidas
· Satisfação do cliente
· Redução de custos
DESVANTAGENS:
· Necessidade por mudança cultural da empresa
· Custo de transição
· Dificuldade em manter
· Muitas mensagens de erro
· Falta de pessoal capacitado
Boas práticas
· Automação Build
· Testes automatizados
· Automatizar as implantações
· Commits em uma branch master
· Manter a construção rápida
· Processo deve ser consertado o quanto antes
· Pessoa responsávelFerramenta:
Jenkins
AULA 8
Auditoria de Configuração
Software e itens de configuração que o compõem precisam aderir a algum tipo de especificação de performance. Independentemente de como esta documentação será conhecida ou intitulada dentro de cada organização, ela invariavelmente irá prover requisitos e restrições as quais estes itens de configuração precisam obedecer.
Verificação - A verificação é conduzida pela equipe de testes/equipe de qualidade, focando em encontrar defeitos
Validação - A validação é conduzida pelo cliente, especificamente pelos usuários, que focarão em assegurar que o software é aderente aos requisitos.
Fica claro que ambos os termos se referem ao exame do software, antes de sua entrega definitiva, de forma a assegurar que ele é aceitável quando comparado ao que foi contratado.
As auditorias de configuração vem se somar aos exames promovidos pela verificação e validação.
Outro ponto pertinente às auditorias é que o desenvolvimento de um item gera todo tipo de documentação, sobretudo documentação de produto. É esperado que tal documentação seja fiel representação do desenho do produto sendo entregue.
As auditorias de configuração irão fornecer o framework de procedimentos necessários para assegurar que o esforço de desenvolvimento atingiu com sucesso todos os requisitos especificados nas linhas de base de configuração.
Validação do software e da documentação
Tipos de Auditoria de Configuração
A condução destas auditorias normalmente se dão em três passos ou fases distintas:
· Pré-auditoria - Levantamento das especificações. Definir os pontos para a avaliação
· Auditoria em si - Validação
· Pós-auditoria - Analisar os resultados.
Profissionais externos à empresa ou de outros segmentos.
Ajuda na adaptação à GC.
Auditoria funcional - Documentação, software. Testes.
Emitido um relatório.
Plano de ação
Auditoria física - Casos de desenho, casos de uso.
Procedimentos das auditorias
Independente se formais ou informais, fica evidente a necessidade da existência de procedimentos muito bem definidos para as suas realizações.
· Verificar se a documentação e o software estão de acordo com o que foi solicitado na baseline
· Analisar se a mudança foi aplicada de maneira correta. Nível de impacto.
· Não conformidades foram resolvidas?
· Verificar Itens de configuração estão dentro da baseline correta
AULA 9
DevOps
O DevOps é a junção entre Desenvolvimento e Operações. É uma mudança de paradigma fundamental em relação às abordagens tradicionais, em que a fase do Desenvolvimento sempre foi encarada como sendo completamente segregada da se de operações.
Esse conceito de DevOps deixa clara a presença de uma mentalidade ágil, pois com a junção de ambas as fases busca-se obter um relacionamento agilizado entre elas, melhorando a comunicação e encurtando-se o tempo de desenvolvimento, ao mesmo tempo em que produz software de melhor qualidade.
O DevOps facilita a comunicação e a colaboração através das organizações, objetivando a produção e melhoria de produtos de software em um ritmo muito maior do que seria possível caso abordagens tradicionais fossem utilizadas.
Atua na automação de infraestrutura e desenvolvimento.
Automação - entrega contínua - agilidade
Planejar - Codificar - Construir - Testar
Liberar - Implantar - Operar - Monitorar
O DevOps se organiza ao redor de três princípios:
· O principio do Fluxo - Reduzir o tempo da confirmação ao código rodando em produção
· Principio do Feedback - Deve-se aumentar o feedback do desenvolvimento para produção e da produção para o desenvolvimento.
· Princípio do Aprendizado Contínuo e Experimentação - Importancia de aprender continuamente.
O principal pornto cultural que precisa mudar ao se decidir pela adoção do DevOps é a eliminação dos chamados silos funcionais, ou seja, a concepção de que equipes totalmente diferentes devem existir para desenvolvimento e operação de software.
O conhecimento tem que estar em várias pessoas.
Integração contínua
Entrega continua - Automatização para entregar de maneira mais rapida e com qualidade.
O DevOps prega que deve existir uma maior comunicação entre o desenvolvedor e o cliente.
Vantagens e desvantagens
VANTAGENS
· Redução no tempo necessário para o desenvolvimento.
· Redução no número de profissionais e custos associados - Devido a automação e profissionais atuando tanto em desenvolvimento e operações
· Possivel endereçamento de questões relacionadas a segurança
· Auto-responsabilização dos membros da equipe.
DESVANTAGENS
· Problemas relacionados a segurança
· Mudança cultural
· Necessidade em lidar com experiências individuais historicas
image2.png
image1.jpg