# Plano de Gerenciamento de Configuração de Software ## Plano de Gerenciamento de Configuração de Software ### Histórico de Revisão | Data | Versão | Responsável | Mudança realizada | | -------------- | ------ | ------------------------ | ------------------------------------------------ | | **12/11/2018** | 0.1 | Caio Nunes, Gustavo Braz | Criação do Documento de Configuração de Software | ### 1 Introdução O Plano de Gerência de Configuração do School4Home apresenta todas as tarefas do Gerenciamento de configuração e mudanças no projeto, para garantir a sua integridade e manter o domínio das mudanças ocorridas durante o desenvolvimento. Neste documento detalha-se toda a infraestrutura utilizada nesse projeto. São definidos itens como: uma padronização para os documentos, uma ferramenta de controle da instalação da aplicação, preparo do ambiente de desenvolvimento de forma otimizada, integração ferramenta de controle de testes e por fim relatar os resultados da implantação da gerência de configuração de software. Para isso, devem ser seguidas diretrizes apresentadas em tópicos pelo plano de gerência. #### 1.1 Resultados esperados Com a implantação deste plano espera-se diminuir as ocorrências de problemas na configuração da aplicação em outros ambientes, além de garantir maior qualidade no desenvolvimento de testes da aplicação, assegurando que as entregas de software aceitas estejam no nível aceitável definido pela equipe de gerência. #### 1.4 Definições, Acrônimos e Abreviações | Termo | Significado | | ---------- | --------------------------------------------------------------------------------------- | | *Baseline* | Conjunto de itens de configuração que conseguiram um estado comprovado de estabilidade. | | GCS | Gerência de Configuração de *Software* | | CR | Solicitação de Mudança (*Change Request*) | ### 2 Organização #### 2.1 Identificação dos documentos Todos os artefatos produzidos devem manter o nome seguindo o título do artefato sem abreviação. Ex:`Plano de Gerência de Configuração`. Os únicos artefatos que podem ter abreviação são as `Histórias de Usuário`. Neste caso, o nome do artefato deverá ser: `US - `. #### 2.2 Versão dos Artefatos O versionamento dos artefatos será feito por tabela de Histórico de Versão no próprio documento. Os artefatos podem ser desenvolvidos na ferramenta Google Drive, ou diretamente no Gitbook. #### 2.3 *Baseline* do Projeto A baseline será gerada a cada fim de sprint do projeto, tendo assim um incremento no número da versão do sistema `1.0`, no caso de atualizações e correções de erros em versões passadas, deve-se utilizar o código da versão anterior sendo que o dígito após o "ponto" deve ser acrescido um `1.1`. #### 2.4 *Branches* Essa seção determina as políticas de *branches* utilizada no processo. * Haverão duas *branches* principais, a **master** e a **development**; * A master manterá a versão entregável do projeto; * A *development* será utilizada para a equipe de gestão avaliar os *commits* e coletar as métricas; * O incremento à master, ocorrerá através de *pull request* advindo da *branch development* e será de responsabilidade exclusiva da equipe de gestão; * O incremento à *development* ocorrerá através de *pull request* advindo das *branches* de desenvolvimento, onde a aceitação ou recusa do *pull request* será de responsabilidade da equipe de gestão; * Só poderão ser criadas *branches* de desenvolvimento apenas se forem relacionadas a casos de usos à serem implementados ou para mudanças no sistema; * O nome das *branches* de desenvolvimento devem seguir o modelo `us_.` Obs.: Se o nome do caso de uso/mudanças no sistema conter espaços, estes devem ser substituídos por `underline` e todas as letras devem ser minúsculas. ### 4. Commits #### 4.1 Comentário do *commit* Os nomes dos commits devem ser relevantes ao conteúdo inserido ou retirado do repositório. Devem ser inscritos em língua Inglesa e conteúdo significativo, suficiente para identificação do que e onde houve alteração de código. > Exemplo: `git commit -m "Added first list of mailing lists in manage subscriptions"` #### 4.2 Política de Commits Quando houver pareamento em um *commit* deve-se usar: > Exemplo: `git commit --author user_name` Em que o *user\_name* é o nome do usuário com o qual está pareando. > Exemplo: `git commit --author vinisilvacar` O commit deverá estar associado diretamente a um membro da equipe. No caso de pareamento, o commit deve possuir a assinatura de ambos. O *commit* deverá ter uma descrição para indicar o que foi solucionado. Outra forma de editar um *commit* seria o uso do comando: > Exemplo: `git commit -s` Este comando abrirá o editor de texto e deverá seguir o seguinte padrão: O título para o commit, o nome da tarefa em desenvolvimento, uma breve descrição para o que foi feito naquele commit e o `Signed-off-by: "Nome do Usuario" example@email.com` mesmo se o commit foi dado apenas por uma pessoa. Ao fazer pareamento ou dojo deve haver o Signed-off-by com todos os contribuidores. ![Editor de Texto com comando -s](https://raw.githubusercontent.com/wiki/fga-gpp-mds/2017.1-SIGS/images/comandoGitCommitS.png) #### 4.3 Solicitação de Mudanças Deve seguir o tópico 4.1 e no conteúdo do *commit* e deve haver o código da *issue* gerado pelo Github. > Exemplo: `git commit -m "issue #X Added first list of mailing lists in manage subscriptions"` ### 5. Ferramentas A tabela abaixo descreve as ferramentas que serão utilizadas no desenvolvimento do projeto School4Home. | Ferramenta | Descrição | | | ---------- | -------------------------------------------- | ----- | | Travis CI | Integração Contínua | | | Git | Controle de Versão | | | Github | Serviço Web Hosting Compartilhado | | | Python | Linguagem de Desenvolvimento | 3.6.1 | | Django | Framework de Desenvolvimento Web para Python | | #### 6.1 TravisCI O Travis CI proporciona um ambiente de build padrão e um conjunto padrão de etapas para cada linguagem de programação. É possível personalizar qualquer passo neste processo através do arquivo ''.travis.yml''. O Travis CI usa o arquivo .travis.yml na raiz do repositório para tomar conhecimento sobre o projeto e como a build deve ser executada. O travis.yml pode ser escrito de forma minimalista ou detalhado. Alguns exemplos de que tipo de informação o arquivo .travis.yml pode ter: * Que linguagem de programação o projeto usa; * Quais comandos ou scripts devem ser executados antes de cada compilação (por exemplo, para instalar ou clonar as dependências do projeto); * Qual comando é usado para executar o conjunto de testes. **6.1.1 Motivação** As principais motivações para a escolha do Travis CI foram: * Ele é gratuito para repositórios públicos; * Ser um serviço de Integração Contínua na nuvem que pode ser conectado a repositórios no GitHub; * Notifica o usuário (por e-mail) sobre resultados da build; * Vasta documentação; * Rápida curva de aprendizado. ### --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://school4home.gitbook.io/project/abordagem-metodologica/plano-de-gerenciamento-de-configuracao-de-software.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.