Exibir código-fonte para Plano de gerência de configuração

<!--
{| {{table}}
| align="center" style="background:#f0f0f0;"|'''Versão'''
| align="center" style="background:#f0f0f0;"|'''Data'''
| align="center" style="background:#f0f0f0;"|'''Autor'''
| align="center" style="background:#f0f0f0;"|'''Descrição'''
|-
| 0.9||10/05/2011||"Paulo C. Araújo Silva Filho<br>Raphael D'Castro (TJPE)"||Versão inicial
|-
| 1.0||26/05/2011||Olívio F. Balbino, PMP||Revisão
|-
|}
-->
O plano de gerência de configuração da gerência de desenvolvimento do sistema PJe compreende as informações pertinentes à padronização de repositório para armazenamento de código fonte e documentação do sistema, assim como nomenclatura dos itens de configuração e informações relativas ao versionamento de itens e do próprio sistema.<br>
Esse plano será aplicado no âmbito da gerência geral do projeto e das equipes de desenvolvimento prevista no plano de projeto em sua versão mais recente.
== Público-Alvo ==
O presente documento se destina aos envolvidos no desenvolvimento do sistema PJe, seja no próprio Conselho Nacional de Justiça, seja nas equipes de desenvolvimento formadas por órgãos ou tribunais participantes do projeto.<br>
Este documento não se destina ao desenvolvimento feito dentro de fábricas de software terceirizadas, desde que, nas entregas de artefatos, essas fábricas apresentem o produto dentro das presentes especificações, termos e abreviações.
== Convenções deste documento ==
Para melhor apreensão deste manual, serão adotadas algumas convenções de conceitos e exibição de informações.
=== Conceitos, termos e abreviações ===
Esta seção apresenta o conceito ou a abreviação de alguns termos importantes que serão mencionados no documento, todos relacionados ao processo de gerência de configuração de software.
{| {{table border=1 width="70%"}}
| align="center" style="background:#f0f0f0;"|'''Termo/Abreviação'''
| align="center" style="background:#f0f0f0;"|'''Termo/Abreviação'''
|-
| Artefato||Qualquer produto do ciclo de produção do projeto, podendo ser arquivos eletrônicos de código fonte, arquivos eletrônicos de código compilado, a reunião desses arquivos, arquivos de documentação ou mesmo objetos físicos, como manuais impressos ou discos de instalação.
|-
| Baseline||Conjunto de artefatos aprovados e revisados que serão utilizados para atividades posteriores. É definida pela gerência de projeto como base para evoluções e desenvolvimento futuro.
|-
| Branch||Linha de desenvolvimento paralela à linha principal do repositório de código fonte e documentação.
|-
| Build||Versão ainda incompleta do sistema em desenvolvimento, capaz de ser executada em um ambiente regularmente configurado. Contém arquivos de instalação, código fonte, arquivos de dados, programas ou scripts de instalação e documentação básica.
|-
| CG||Comitê gestor do projeto.
|-
| GCS||Gerência de configuração de software.
|-
| Gerente de configuração||Responsável pelas atividades relacionadas ao respeito das regras estabelecidas no presente documento, assim como à revisão dessas regras conforme definido pelos comitês pertinentes.
|-
| GG||Gerência geral do projeto.
|-
| GM||Grupo de mudanças do projeto.
|-
| Item de configuração||Qualquer artefato produzido durante o ciclo de vida do projeto cuja mudança será controlada por um processo formal.
|-
| JIRA/CNJ||Ferramenta WEB de controle de demandas de projetos de elaboração ou evolução de software utilizada pelo CNJ.
|-
| Merge||Operação de integração de alterações de um determinado branch (ramo) ao trunk ou a outro branch.
|-
| PGCS||Plano de gerência de configuração de software – a versão mais atualizada deste documento.
|-
| Ramo||Ver branch.
|-
| Release||Versão do sistema validada para instalação, seja em produção, seja para homologação. Conjunto de itens enviado a um tribunal ou a um departamento para instalação, que não deve conter o código fonte do sistema. Cada release pode encerrar novas funcionalidades ou mudanças decorrentes de evolução do sistema.
|-
| Repositório|| Sistema de controle de versões de artefatos eletrônicos em que os itens de configuração eletrônicos são armazenados com a garantia de possibilidade de reversão a uma versão anterior do item.
|-
| Tag||Rótulo de identificação de um conjunto de itens de configuração que representa um todo de interesse. Ordinariamente, as versões de release e as baselines são identificadas com tags para melhor referência.
|-
| Trunk||Linha principal de desenvolvimento existente no repositório.
|}

=== Dado de entrada ===
Ao fazer referência a um dado a ser inserido pelo usuário, será utilizado o seguinte formato: dado a ser inserido pelo usuário.
== Gerenciamento de configuração de software ==
=== Responsabilidades ===
A gerência de configuração é atividade exercida por três papéis, cujas responsabilidades são descritas na tabela abaixo.
{| {{table border=1 width="70%"}}
| align="center" style="background:#f0f0f0;"|'''Papel'''
| align="center" style="background:#f0f0f0;"|'''Responsabilidades'''
|-
| Gerente de configuração ou integrador de configuração||i. elaborar e ajustar o PGCS;<br>ii. controlar as baselines dos produtos;<br>iii. realizar a integração (merge) junto às equipes de desenvolvimento;<br>iv. realizar auditorias para garantir o cumprimento das atividades de GCS pelas equipes de trabalho;<br>v. informar o status da configuração;<br>vi. definir permissões de acesso aos repositórios;<br>vii. gerar tags;<br>viii. gerar branchs;<br>ix. gerar builds;<br>x. gerar releases.
|-
| desenvolvedor||i. respeitar as definições do PGCS quando da elaboração ou modificação dos artefatos afetados pela GCS (itens de configuração) a eles atribuídos;<br>ii. realizar a integração (merge) com a gerência de configuração;<br>iii. gerar builds a pedido da gerência de configuração;<br>iv. gerar releases a pedido da gerência de configuração.
|-
| Analista de sistema||i. respeitar as definições do PGCS quando da elaboração ou modificação dos artefatos afetados pela GCS (itens de configuração) a eles atribuídos.
|}

=== Ferramentas, ambiente e infraestrutura ===
As seguintes ferramentas são utilizadas para manter o controle da gerência de configuração:
* subversion <versão>
* <cliente de SVN para Windows>
* subversive team integration sobre Eclipse IDE
* Atlassian Connector sobre Eclipse IDE
* redmine
* mediawiki

=== Identificação da configuração ===
Esta seção aborda os temas referentes à identificação dos itens de configuração eletrônicos, assim como, a identificação de itens de configuração físicos referenciados por itens de configuração eletrônicos.<br>
Qualquer artefato produzido durante o ciclo de vida do projeto cuja mudança será controlada por um processo formal é um item de configuração.
==== Identificação dos itens de configuração ====
===== Código fonte =====
A identificação dos arquivos de código fonte seguirá regras específicas definidas em documento de desenvolvimento.
===== Demais itens de configuração =====
Os demais itens de configuração devem ser identificados com caracteres minúsculos e não especiais, podendo-se utilizar as regras de capitalização de letras dos JavaBeans para descritores. A estrutura de identificação é:<br><br>
                                               pje_<idartefato>
, onde <idartefato> é a identificação do item de configuração. Na tabela a seguir estão expostos os itens de configuração afetados pela presente regra com o formato de seus identificadores. <!--Os itens de configuração destacados são imprescindíveis para o projeto, e os demais devem ser elaborados à medida que o projeto amadurecer.-->

{| {{table border=1 width="70%"}}
| align="center" style="background:#f0f0f0;"|'''Item'''
| align="center" style="background:#f0f0f0;"|'''Identificador'''
| align="center" style="background:#f0f0f0;"|'''Descritor'''
| align="center" style="background:#f0f0f0;"|'''Exemplo do descritor'''
|-
| ata de reunião||arAAAAMMDD_<descritor>||assunto principal||ar20110506_PlanoProjeto
|-
| caso de teste||cdt_<descritor>||nome do caso||cdt_AutuarProcesso
|-
| caso de teste de integração||cti_<descritor>||nome do caso||cti_AutuarProcesso
|-
| caso de uso||cdu_<descritor>||nome do caso||cdu1001_AutuarProcesso
|-
| cronograma||cr_<descritor>||versão||cr_1.0.0
|-
| diagrama de classes||dc_<descritor> - nome do caso de referência<br> - identificação do conjunto de funcionalidades<br>- “geral”||dc_AutuarProcesso<br>dc_AutuacaoDistribuicao<br>dc_geral
|-
| diagrama de sequência||ds_<descritor>||idem||ds_AutuarProcesso<br>ds_AutuacaoDistribuicao<br>ds_geral
|-
| documento de arquitetura do sistema||das_<descritor>||versão||das_1.0.0
|-
| documento de visão||dv_<descritor>||versão||dv_1.0.0
|-
| especificação de mensagens do sistema||ems_<descritor>||- nome do caso de referência<br>- identificação do conjunto de funcionalidades<br>- “geral”||ems_AutuarProcesso<br>ems_AutuacaoDistribuicao<br>ems_geral
|-
| especificação de regras de negócio||ern_<descritor>|| - nome do caso de referência<br>- identificação do conjunto de funcionalidades<br>- “geral”||ern_AutuarProcesso<br>ern_AutuacaoDistribuicao<br>ern_geral
|-
| especificação suplementar||esu_<descritor>|| - nome do caso de referência<br>- identificação do conjunto de funcionalidades<br>- “geral”||esu_AutuarProcesso<br>esu_AutuacaoDistribuicao<br>esu_geral
|-
| guia de instalação e configuração||gic_<descritor>||versão||gic_1.1.2
|-
| glossário||glo_<descritor>||versão||glo_1.0.0
|-
| manual de instalação||mai_<descritor>||versão||mai_1.0.0
|-
| manual de usuário||mdu__<descritor>||versão||mdu_advogado_1.0.0
|-
| modelo conceitual de dados||mcd_<descritor>||versão||mcd_1.0.0
|-
| modelo lógico de dados||mld_<descritor>||versão||mld_1.0.0
|-
| planilha de acompanhamento de ciclo||pac_<descritor>||número do ciclo projetado||pac_0230
|-
| planilha de riscos||plr_<descritor>||versão||plr_1.0.0
|-
| plano de garantia de qualidade do projeto||pgqp_<descritor>||versão||pgqp_1.0.0
|-
| plano de gerência de configuração do projeto||pgcp_<descritor>||versão||pgcp_1.0.0
|-
| plano de projeto||pp_<descritor>||versão||pp_1.0.0
|-
| plano de testes||pt_<descritor>||- nome do caso de referência<br>- identificação do conjunto de funcionalidades<br>-versão||pt_AutuarProcesso<br>pt_AutuacaoDistribuicao<br>pt_1.0.0
|-
| relação de casos de uso||rcdu_<descritor>||- identificação do conjunto de funcionalidades<br>- versão||rcdu_AutuacaoDistribuicao<br>rcdu_1.0.0
|-
| relatório de análise de impacto||rai_<descritor>||identificação da demanda analisada||rai_pje112
|-
| notas de versão||notasversao_<descritor>||versão||notasversao_1.0.10
|-
| termo de aceite||ta_<descritor>||- identificador da ordem de serviço<br>- identificador da demanda repassada||ta_os123<br>ta_pje112
|}

==== Localização dos itens de configuração ====
Esta seção descreve o modo e a estrutura de armazenamento dos itens de configuração.<br>
Os itens de configuração são divididos em duas classes
* Artefatos de gerência: artefatos gerais, que demandam controle de versão, mas cujas alterações não são diretamente vinculadas aos lançamentos de versões do sistema. Fazem parte desse grupo os seguintes artefatos:
** Ata de reunião;
** Cronograma;
** Documento de arquitetura do sistema;
** Documento de visão do negócio;
** Documento de visão do sistema;
** Glossário;
** Planilha de acompanhamento de ciclo;
** Planilha de riscos;
** Plano de garantia de qualidade do projeto;
** Plano de gerência de configuração do projeto;
** Plano do projeto.
* Artefatos de desenvolvimento: artefatos diretamente ligados ao desenvolvimento, englobando todo o código fonte, os scripts de bancos de dados, os dumps de bancos de dados e todos os documentos listados na tabela da seção anterior e não identificados como documentos de gerência.
===== Localização dos documentos de gerência =====
Os artefatos de gerência são mantidos na ferramenta Redmine no endereço:
* http://colaboracao.cnj.jus.br/projects/sisprocessual
A manutenção desses artefatos na ferramenta de colaboração será feita de duas formas:
* Versões dinâmicas: mantidos na área de Wiki;
* Versões estáticas: extraídos ou elaborados a partir dos documentos constantes na área de Wiki, armazenados na área de repositório de documentos com numeração de versão, conforme regras adiante.<br>
A regra geral é manter os artefatos na área de Wiki. Em razão da natureza multidirecional de páginas Web tais como as wiki’s, as referências de estruturação a seguir apresentadas são as mínimas, ou seja, são aquelas essenciais e dirigidas à apreensão direta dos conhecimentos envolvidos nos artefatos. Desse modo, o gráfico a seguir se limita a indicar os artefatos essenciais e as ligações mínimas existentes entre eles em uma estrutura de árvore, ainda que, na realidade, essa estrutura se assemelhe mais com uma teia.
[[imagem:teiaversoes.jpg|700px]]<br>
Esses documentos devem ser mantidos sempre atualizados e, ao se concluir pela aprovação de uma determinada versão segundo os critérios abaixo, deverão ser produzidas versões em formato de documento portável (PDF) ou formato de documento aberto (ODT), que serão gravadas nas áreas homônimas da documentação.
===== Localização dos documentos de desenvolvimento =====
As presentes regras tomam por base um diretório raiz <RAIZ> no servidor que hospeda a solução de software de controle de versionamento, a partir da qual são definidos os caminhos do sistema.<br>
O acesso externo ao repositório do sistema de controle de versionamento será efetivado por meio do endereço:
* https://wwwh.cnj.jus.br/svn/projeto_pje
Haverá um único repositório para o projeto, o trunk. Cada um dos branchs e cada uma das tags deve ter a seguinte estrutura interna. Nela, estão representados os arquivos:
{| {{table border=1 width="70%"}}
| rowspan="13" |raiz 
| rowspan="11" |trunk
| |aplicacao
| colspan="2" |Projeto na IDE
|- 
| rowspan="10"|documentacao ||rowspan="5"|analise || casosdeuso
|-
| modelosartefatos
|-
| regrasdenegocio
|-
| requisitos
|-
| rcdu (arquivo)
|-
| rowspan="3"|bancodedados||conversao
|-
| |dumps
|-
| |importacao
|-
| rowspan="2"|qualidade||homologacao
|-
| |testes
|-
| branches||nome do branch/ramo||colspan="2"|Estrutura idêntica à do trunk
|-
| tags||nome da tag||colspan="2"|Estrutura idêntica à do trunk
|-
|}

                         [[imagem:arvorepastas.jpg]]

Os projetos em ambiente de desenvolvimento integrado devem ser estruturados seguindo os padrões definidos no documento de regras de desenvolvimento, respeitando, ainda, a versão pertinente.<br>
É importante lembrar que, nos projetos em ambiente de desenvolvimento integrados, as pastas de destino do código compilado não devem ser mantidas sob o controle de versão, assim como arquivos de configuração locais.

=== Histórico ===
O controle de versões do código fonte será feito exclusivamente por meio do sistema de controle de versões, sobre cada um dos projetos de desenvolvimento. Os demais artefatos deverão ser controlados tanto por esse sistema quanto por indicações textuais contidas no identificador de
versão do nome do arquivo e em seção específica de histórico de alterações. O controle de histórico de versões de artefatos de gerência e de artefatos de desenvolvimento diversos do código fonte será feito pela descrição das alterações havidas entre cada uma das versões.<br>
Cada um desses documentos deve conter uma seção denominada “Histórico” em que está contida uma tabela contendo número da versão, data da versão, responsável e uma descrição das alterações havidas, seguindo o seguinte modelo:
{|border=1 {{table}}
| align="center" style="background:#f0f0f0;"|'''Versão'''
| align="center" style="background:#f0f0f0;"|''' Data'''
| align="center" style="background:#f0f0f0;"|'''Autor'''
| align="center" style="background:#f0f0f0;"|'''Descrição'''
|-
| 0.1.0 ||01/01/2011||Paulo C. Araújo Silva Filho<br>Raphael D'Castro (TJPE)||Versão inicial
|-
| 0.2.0||01/02/2011|| Marivaldo Dantas de Araújo ||Inclusão da seção 5
|-
| 0.2.1 ||03/02/2011||Marivaldo Dantas de Araújo||Correções ortográficas
|-
|}

=== Versionamento ===
==== Regras de versionamento de artefatos de gerência ====
Os artefatos de gerência devem ser versionados seguindo o seguinte padrão:
 X.Y.Z
, onde:
{|border=1 {{table}}
|| X
||Número principal da versão, somente alterado quando há uma significativa mudança na estrutura do documento após o lançamento da primeira versão principal. Por significativa mudança, compreenda-se a inclusão de novas seções, a inclusão de novas estruturas ou regras não decorrentes das regras originais. Esse número deve ser 0 para versões em rascunho originárias.
|-
| Y||Número intermediário de versão, modificado sempre que houver inclusão ou supressão de parágrafos dentro de seções antes existentes, mas que não representam a modificação de uma estrutura já existente. Esse número deve iniciar em 0 e reiniciado quando da troca do número principal.
|-
| Z||Número menor de versão, modificado sempre que houver modificação da versão em razão de correção ortográfica ou esclarecimento de regra já estabelecida no documento. Esse número deve iniciar em 0, para as versões em rascunho de uma versão principal 0, ou 0rN, para versões em rascunho de uma versão principal superior à 1. Esse número deve ser zerado quando da troca do número intermediário ou do número principal.
|-
|}


A partir de tais regras, um artefato de gerência em rascunho originário deverá ser numerado como 0.1.0, evoluindo esse número até sua aprovação como documento válido, caso em que receberá a numeração 1.0.0. A partir daí, correções ortográficas implicarão em acréscimo no número menor,
evoluindo a versão para a numeração 1.0.1, inserção de novos parágrafos ou supressão de novos parágrafos implicarão em acréscimo de número intermediário (1.1.0) e a inserção de novas seções ou substituição de estruturas deverá resultar na criação de uma versão principal maior
(2.0.0). Caso haja mera preparação de uma versão nova superior à primeira versão principal já tornada válida (1.0.0), dever-se-á adotar a numeração X.0.0r0 (2.0.0r0, no exemplo).

==== 5.2 Regras de versionamento de software ====
As regras estabelecidas no presente tópico tratam das versões liberadas do sistema, quer a liberação seja para uso em homologação, quer a liberação seja para uso em produção. Também se define as regras para a nomeação das versões, quando elas apresentarem um número.<br>
===== Números das versões do sistema =====
O sistema terá versões numeradas seguindo o seguinte padrão:
 X.Y.Z
, onde:

{|border=1 {{table}}
||X
||Número principal da versão, somente alterado quando:<br> 
a) há modificação de arquitetura do sistema, ainda que não tenha havido modificação da estrutura de dados;<br>
b) há modificação da estrutura de dados que demande uma migração significativa de uma base para outra base de dados, não sendo suficiente a mera concretização de scripts de migração de dados entre tabelas de um mesmo banco de dados. <br>
Esse número deve ser 0 para a versão anterior à primeira.
|-
| Y||Número intermediário de versão, modificado sempre que houver inclusão de um ou mais conjuntos de novas funcionalidades. Esse número deve iniciar em 0 e reiniciado quando da troca do número principal.
|-
| Z||Número menor de versão, modificado sempre que liberada versão de correção de erros ou de comportamento esperado na versão do sistema. Esse número deve iniciar em 0 e reiniciado quando da troca do número intermediário ou do número principal. Para versões intermediárias ou principais novas, antes da homologação, esse número deverá ser acrescido do milestone de liberação (M1, M2, M3 etc.) até que a versão seja homologada, quando receberá o número menor.
|-
|}

==== Nomes das versões do sistema ====
As versões intermediárias do sistema receberão o nome de município brasileiro iniciado na letra de referência da versão, estas na ordem alfabética, que não contenha espaços ou caracteres especiais, obtidos a partir do nome das unidades federativas, essas na ordem alfabética inversa.
Assim, por exemplo, temos:
{|border=1 {{table}}
| align="center" |Versão
| align="center" |Letra de referência
| align="center" |Unidade Federativa
| align="center" |Município existente na letra de referência
|-
| 1.0 ||A||Tocantins ||Alvorada
|-
| 1.1 ||B ||Sergipe ||Balbinos
|-
| 1.2||C||São Paulo||Capela
|-
| 1.4|| D||Santa Catarina||Descanso
|-
| 2.0||E||Roraima||Esmeralda
|-
|}

==== Versões de bibliotecas ou projetos utilitários do sistema ====
As bibliotecas ou projetos utilitários do sistema receberão sua numeração seguindo as seguintes regras:
 X.Y.Z
, onde:<br>
{|border=1 {{table}}
| X||Número principal da versão, a ser alterada quando:a) opcionalmente, os desenvolvedores incluíram na versão substanciais alterações que melhoram as funcionalidades existentes; b) obrigatoriamente, quando a nova versão não é compatível, em nível de interface, com a versão de produção atual. A compatibilidade em nível de interface existe quando, substituída uma versão por outra em um projeto que somente faz uso das interfaces públicas da biblioteca, não há erro de compilação. Esse número deve ser 0 para a versão anterior à primeira.
|-
| Y||Número intermediário de versão, a ser alterado quando há acréscimos de funcionalidades em relação à versão anterior e não foi mantida a compatibilidade em nível de interface. Esse número deve iniciar em 0 e reiniciado quando da troca do número principal.
|-
| Z||Número menor de versão, modificado sempre que liberada versão de correção de erros ou de comportamento esperado na versão do sistema. Esse número deve iniciar em 0 e reiniciado quando da troca do número intermediário ou do número principal. Para versões intermediárias ou principais novas, antes da homologação, esse número deverá ser acrescido do milestone de liberação (M1, M2, M3 etc.) até que a versão seja homologada, quando receberá o número menor.
|-
|}

==== Versões de banco de dados ====
Os dumps de bancos de dados seguirão a nomenclatura da versão a que estão vinculadas, acrescido de descritor de seu conteúdo, quando necessário. <br>Exemplos:
* pjedb_1.0.1_treinamento.backup
* pjedb_1.0.1_treinamentobin.backup
* pjedb_1.0.1_limpa.backup
* pjedb_1.0.1_limpabin.backup
* pjedb_1.2.0_limpa.backup
No caso de scripts de bancos de dados, deverá ser seguida a seguinte regra de nomenclatura:
* pjescript_importacao_<versaodestino>_<descricao>.sql
* pjescript_conversao_<vorigem>-<vdestino>_descricao.sql
, onde a descrição é opcional.<br><br>
Exemplos:
• pjescript_importacao_1.0.1_cep.sql
• pjescript_conversao_1.0.1-1.0.1.sql
• pjescript_importacao_1.0.1_cnae.sql
==== Política de criação de versões ====
As versões principais e intermediárias dependem, para sua criação, de definição da gerência geral do projeto, que também deverá delimitar o escopo da versão a ser elaborada.<br>
As versões menores serão criadas à medida que forem liberadas as versões menores, devendo sempre haver a previsão de uma futura versão menor assim que liberada a imediatamente anterior, com vistas a permitir a elaboração de versão de correção de urgência.
==== Política de criação de branches ====
O desenvolvimento principal da versão atual do sistema será feito no trunk do projeto, exceto quando houver desenvolvimento concomitante entre duas versões principais, caso em que o trunk será utilizado para o desenvolvimento da versão principal de maior número e será aberto um
branch da versão principal de menor número no formato X.Y.x.<br>
Em um cenário de desenvolvimento normal, ele será efetivado no trunk do projeto até a liberação da primeira versão menor, quando deverá ser criado um branch ou ramo designado principal.intermediário.x. Assim, liberada a versão 1.0.0, devem ser adotadas as seguintes providências:
* criar uma tag com o número da versão liberada (1.0.0);
* criar um branch com o número da versão liberada, substituindo o número menor por “x” (1.0.x);
* o trunk deverá passar a ser utilizado para a elaboração da versão intermediária ou principal seguinte;
* o branch da versão liberada será utilizado para formação das tags de versões menores dessa versão (1.0.1, 1.0.2 etc.)
Adotadas tais providências, a manutenção da versão liberada deverá ser feita no branch da versão, sem prejuízo de essas manutenções serem integradas com o trunk, que deverá passar a ser utilizado exclusivamente com o objetivo de liberar a versão intermediária subsequente (1.1.0).<br>
Caso haja desenvolvimento concomitante de uma versão intermediária e de uma versão principal, além dos passos descritos acima, dever-se-á criar um branch da nova versão intermediária (no exemplo, 1.1.x), do qual será extraído a tag da versão homologada, deixando o trunk para desenvolvimento da versão principal nova (2.0)<br>
Ao criar um branch o usuário deverá comentar a operação com o padrão:<br>
 Criação do BRANCH PJe <versão intermediária> (<nome>)
===== Funcionalides novas =====
A critério da gerência geral do projeto poderão ser criados branchs para desenvolvimento de conjuntos de funcionalidades novas que, por suas características, possam implicar em significativa modificação do código fonte. Nesses casos, o branch deverá ser identificado com o número da
versão de origem seguido de “_<descricao>”. Exemplo: 1.0.x_criminal; 1.0.x_revisao; 1.0.x_oracle. Esses branches deverão ser utilizados exclusivamente para posterior integração com o trunk ou com o branch específico da versão de origem.
==== Política de criação de tags ====
As tags serão criadas sempre que houver nova liberação do sistema para implantação em órgão diverso do CNJ. A nova tag deverá ser extraída:<br>
a) do trunk do sistema, quando da liberação de versão principal ou intermediária, em um ciclo de desenvolvimento normal;<br>
b) do branch da versão intermediária, quando da liberação de versão menor; ou<br>
c) do branch da versão intermediária, quando da liberação de versão intermediária originária se ela estiver em desenvolvimento concomitante com uma versão principal superior.<br>
As tags serão identificadas pelo número da versão do sistema, inclusive o número menor, acrescentando-se:
* Mn: a letra “M” seguida de um número sequencial, enquanto não iniciado o processo de homologação da primeira versão intermediária daquela versão;
* Hn: a letra “H” seguida de um número sequencial, enquanto não finalizada a homologação da primeira versão intermediária.
As tags M deverão ser apagadas quando liberada a primeira versão de homologação e as tags H quando liberada a primeira versão homologada.<br>
Ao ser criada uma tag, o usuário deverá comentar a operação com o padrão:
 Criação da TAG PJe <versãotag> (<nome>
==== Política de realização de integração ====
Homologadas alterações realizadas em um branch elas devem ser integradas com o trunk ou com a branch de versão intermediária vinculada ao branch das alterações.<br>
As submissões de códigos fonte decorrentes de tais integrações deverão ser feitos com a inclusão do comentário padronizado a seguir:
 Merge entre: <tag/branch origem> e <branch/trunk destino>
==== Política de submissões (commits) ====
A operação de submissão de códigos fonte deverá ser sempre precedida de uma atualização da cópia de trabalho do desenvolvedor, que deverá assegurar que eventuais conflitos de código não impeçam a compilação ou inicialização do sistema.<br>
Os commits deverão ser realizados diariamente ou sempre que concluída a elaboração de uma funcionalidade ou correção de um erro designados como demanda no JIRA.<br>
Ao submeter o código, o desenvolvedor deverá mencionar, em alguma parte do comentário, o identificador da demanda no JIRA no formato de sua apresentação nesse sistema (PJE-NNN...).<br>
Também deverá indicar se a submissão conclui seu trabalho na demanda. Jamais deve ser feita submissão de código fonte que impeça a compilação ou a inicialização do sistema.
 Os diretórios de compilação dos projetos devem ser excluídos do controle de versões.
=== Versões previstas ===
O PJe será elaborado e liberado em versões periódicas, com ciclos de desenvolvimento por versões em que há acréscimos de conjuntos de funcionalidades entre elas. Uma versão prevista pode ser suprimida do ciclo de desenvolvimento se constatada a inviabilidade de sua liberação
tempestiva.<br><br>
As versões previstas são:
{|border=1 {{table}}
| '''Versão'''||'''Nome'''||'''Descrição'''
|-
| 0||Marco Zero||Primeira versão integrada do sistema, elaborada a partir do código fonte fornecido pelo Tribunal Regional Federal da 5ª Região.
|-
| 1.0||Alvorada||Primeira versão de produção integrada para uso por tribunais em homologação e produção diretamente controlada pelo Conselho Nacional de Justiça.
|-
| 1.2||Capela||Primeira versão de produção integrada com funcionalidades de instâncias de revisão.
|-
| 1.4||Descanso||Versão do sistema incluindo características de interoperabilidade, replicação nacional e complementação das funcionalidades criminais
|-
| 2.0||Esmeralda||Versão do sistema em nova arquitetura com novas funcionalidades.
|-
|}

=== Política de acesso ===
O PJe encerra um desenvolvimento colaborativo intenso que envolve múltiplas fábricas de software e analistas de sistemas, muitas vezes não localizados no mesmo ponto geográfico brasileiro. Em razão disso e da intensa necessidade de controle do código fonte com vistas a evitar um desenvolvimento não controlado, o acesso aos artefatos do sistema deve ser bem controlado.<br>
Deve-se identificar esses acessos segundo os seguintes papéis:
{|border="1" {{table}}
||Papel
||Sigla
||Descrição
|-
| Membro do CG||CG||Magistrado membro do comitê gestor nacional.
|-
| Gerente geral||GG||Servidor diretamente ligado ao CNJ que gerencia o projeto.
|-
| Gerente de configuração||GC||Servidor diretamente ligado ao CNJ que procura assegurar o respeito ao plano de gerência de configuração.
|-
| Gerente de desenvolvimento||GD||Servidor diretamente ligado ao CNJ que lidera o desenvolvimento do sistema, assegurando que os desenvolvedores respeitem as regras de configuração, de desenvolvimento e os requisitos especificados.
|-
| Gerente de qualidade||GQ||Servidor diretamente ligado ao CNJ que lidera as atividades de testes e homologação de uma versão do sistema.
|-
| Analista de requisitos||AR||Pessoa, servidor ou não, responsável por receber, analisar e formalizar os requisitos de uma determinada funcionalidade do sistema.
|-
| Analista de bancos de dados||ABD||Servidor responsável por avaliar a estrutura de bancos de dados do sistema, com vistas a assegurar sua otimização quando necessário.
|-
| Desenvolvedor||DES||Pessoa, servidor ou não, responsável por implementar um determinado requisito ou caso de uso no sistema.
|-
| Membro de grupo de requisitos||ER||Servidor especialista em um determinado tópico que dará insumos para a preparação dos requisitos e dos casos de uso pertinentes.
|-
| Fábrica||FAB||Tribunal ou terceiro contratado responsável por desenvolver uma determinada funcionalidade ou manter um determinado branch. Cabendo a ela realizar os commits na periodicidade definida neste documento respeitadas as regras estabelecidas de desenvolvimento e qualidade.
|-
 
|}
Tomando por base tais papéis, os acessos devem ser concedidos seguindo a seguinte tabela:
{|border="1" {{table}}
| align="center" style="background:#f0f0f0;"|'''Recurso'''
| align="center" style="background:#f0f0f0;"|'''CG'''
| align="center" style="background:#f0f0f0;"|'''GG'''
| align="center" style="background:#f0f0f0;"|'''GC'''
| align="center" style="background:#f0f0f0;"|'''GD'''
| align="center" style="background:#f0f0f0;"|'''GQ'''
| align="center" style="background:#f0f0f0;"|'''AR'''
| align="center" style="background:#f0f0f0;"|'''ABD'''
| align="center" style="background:#f0f0f0;"|'''DES'''
| align="center" style="background:#f0f0f0;"|'''ER'''
| align="center" style="background:#f0f0f0;"|''' FAB'''
|-
| Wiki – artefatos de gerência||L||LG||LG||LG||LG||L||L||L||L|| L
|-
| /aplicacao|| - ||L||L||LG||L||L||L||LG|| - ||LG*
|-
| /documentacao/analise/rcdu||L||L||LG||L||L||LG||L||L||L||LG*
|-
| /aplicacao/analise/casosdeuso||L||L||LG||L||LG||LG||L||L||L||LG*
|-
| /aplicacao/analise/modelosartefatos||L||LG||LG||L||LG||L||L||L||L|| L
|-
| /aplicacao/analise/regrasdenegocio||L||L||LG||L ||LG ||LG ||L ||L ||L ||LG*
|-
| /aplicacao/requisitos||L||L||LG||L||LG||LG||L||L||L|| LG*
|-
| /aplicacao/bancodedados/* ||L ||L ||LG ||LG ||L ||L ||LG ||L ||L ||LG*
|-
| /aplicacao/qualidade/* ||L ||LG ||LG ||L ||LG ||LG ||L ||L ||L ||LG*
|-
|}
, onde:
* L = leitura
* LG = leitura e gravação
* LG* = leitura e gravação limitadas ao branch afetado a essa fábrica, ou no trunk, se atuando no trunk, devendo ela assegurar que os papéis correspondentes internos, nesses casos, respeitem iguais regras de permissão.