Política de Desenvolvimento de Softwares

A metodologia de desenvolvimento de software do Interlegis utiliza um modelo colaborativo para desenvolver os seus produtos, o qual incentiva a participação da comunidade GITEC para uma atuação conjunta com as suas equipes. A adoção das políticas de desenvolvimento de softwares, por sua vez, procura dar qualidade e segurança aos produtos que disponibiliza bem como clareza das regras aplicadas à gestão e aos seus processos de desenvolvimento e de manutenção dos elementos que compõem cada produto.

Todos são bem-vindos a participar, seja codificando, especificando, documentando, traduzindo, etc. Se você deseja ser um contribuidor dos produtos Interlegis, inscreva-se no Colab, selecionando as listas de discussão de que deseja participar (por exemplo a GITEC e a do(s) produto(s) em que deseja colaborar). Depois envie e-mail para colab@… informando o seu nome de usuário no Colab e solicitando a permissão de escrita no repositório Interlegis.

Políticas

  1. Uma equipe de desenvolvimento é composta pelos membros da comunidade GITEC e pelos técnicos e analistas do Interlegis.
  1. Cada produto tem uma lista de discussões, cujo nome inicia com o nome do software e finaliza com -dev, específica para os desenvolvedores debaterem o escopo e codificação destes. Todos os membros da equipe de desenvolvimento devem estar inscritos nela. http://listas.interlegis.gov.br
  1. Todo o gerenciamento do desenvolvimento dos softwares é realizado através do Colab, mais especificamente através da ferramenta Trac, que contém o wiki de documentação, os códigos fontes, os tickets (tíquetes), o roadmap (planejamento) com seus milestones (marcos) e o timeline (histórico de alterações). http://colab.interlegis.leg.br/wiki
  1. Cada software tem um product owner, que é um analista de sistemas do Interlegis responsável por organizar o escopo e os sprints de desenvolvimento do sistema.
  1. Um novo produto gera um novo componente no Trac, que deverá ser cadastrado pelo respectivo product owner.
  1. Cada nova versão do software deve ser uma versão média (2.0, 2.1, 2.2) e deve ter associado a ela um milestone cadastrado no Colab. http://colab.interlegis.leg.br/roadmap
  1. Cada milestone tem um conjunto de tickets atribuídos, selecionados pelo product owner, em conjunto com a equipe de desenvolvimento.
  1. A entrada de um novo ticket deverá ser pelo Colab e poderá vir de uma história do usuário, de um registro de problema (bug), sugestão de melhoria, solicitações diversas, desmembramento de outro ticket, ou qualquer ação que caracterize uma atividade que necessitará ser realizada no software. http://colab.interlegis.leg.br/newticket
  1. Somente serão implementadas as novas funcionalidades que estiverem no roadmap do produto, conforme registro de milestones. Toda nova funcionalidade proposta pela comunidade deve ser precedida de discussão na respectiva lista -dev do produto e deve ter sua inserção previamente acordada. A inserção pode acontecer tanto via abertura de um novo ticket ou remanejamento de um ticket já existente.
  1. Todos os códigos fontes dos softwares deverão estar sob o controle de versões no repositório do Interlegis, e mesmo que algum esteja utilizando um controle de versões externo (GitHub?, BitBucket?, etc.), deverá estar sincronizado com o repositório Interlegis que é de onde partirão todos os deploys dos produtos. http://repositorio.interlegis.gov.br
  1. O desenvolvimento do sistema ocorrerá sempre no trunk, que é a linha-do-tempo central de desenvolvimento do software, representando a versão instável deste.
  1. Uma versão de testes do produto deve ser distribuída a partir do trunk, não tendo compromisso com estabilidade e migrações.
  1. Uma versão estável do produto deverá gerar uma cópia do trunk para um diretório nomeado com sua versão média no diretório branches e uma cópia deste branch para um diretório com sua versão menor (2.1.0, 2.1.1, 2.1.2) no diretório tags, que é imutável.
  1. Atualizações do sistema, correções de problemas e pequenas melhorias devem ser implementadas no branch estável e mescladas (merge) no trunk, para reaproveitamento em versões futuras. Sempre lembrar de atualizar a cópia-de-trabalho antes de efetuar a alteração do código.
  1. Alterações em banco de dados ou em estruturas que não estão sob o controle de versões no respectivo branch ou sob controle deste, devem ser realizadas somente no trunk, salvo correção de problemas.
  1. Um commit de código no repositório deve ser referente ao fechamento de um ticket ou pequenas implementação de código, evitando-se commits de muitas alterações em vários arquivos para facilitar eventuais reversões e merges, bem como, deve conter uma mensagem clara e detalhada documentando o que foi alterado.
  1. O instalador da versão estável do produto deverá ser gerado a partir do checkout do respectivo diretório branch, para facilitar a atualização do sistema usando o comando update da cópia-de-trabalho. Este instalador deve estar versionado em um diretório nomeado com a versão média do software, no diretório install do seu repositório.
  1. A release do produto deve gerar também uma página wiki no Colab, detalhando o procedimento de instalação, apontando a documentação, o download do instalador e demais informações pertinentes.
  1. Somente será dado suporte para a versão atual estável de cada produto e sua versão estável imediatamente anterior, salvo contribuições espontâneas da comunidade. Correções de problemas em qualquer destas versões devem ser mescladas no trunk e, se pertinente, no outro branch suportado.

Metodologia de Desenvolvimento

Como apoio a estas políticas temos uma página no Colab que organiza a metodologia de desenvolvimento e existe também uma página que concentra ótimas referências às tecnologias utilizadas no desenvolvimento dos produtos Interlegis.

Última modificação 5 anos atrás Última modificação em 21/12/2012 11:02:47
 

The contents and data of this website are published under license:
Creative Commons 4.0 Brasil - Atribuir Fonte - Compartilhar Igual.