Edição atual tal como às 11h34min de 11 de dezembro de 2014

[editar] Sistema de Gerência de Configuração

[editar] Composição

[editar] SVN

SVN: Software de Sistema de Controle de Versão, utilizado tanto para armazenar os fontes como demais artefatos, como diagrama de classes, documentos, arquivos de projetos (cronograma, planilha de acompanhamento de pacotes).

A url do SVN, atualmente é https://atsjavaserver:8443/svn/. Esta deve ser colocada nos clients. A versão utilizada pela empresa deve ser superior a 1.7.2.

Administração e controle de acesso: para administração do SVN, logar no servidor acima (atsjavaserver) como administrador, cuja senha é '475-j4v4'.

[editar] SAC

Ferramenta interna da empresa, onde são armazenados todos os requisitos (evoluções e erros). Cada requisito controlado pelo SAC poderá conter, em formato teoricamente conclusivo, as especificações funcionais, bem como suas aprovações e reprovações, roteiro de testes, documentações técnicas bem como qualquer tipo de documento útil para elucidação destes referidos requisitos.

Administração e controle de acesso: o CPD da Ats é o setor que gera e controla as senhas de acesso.

[editar] Mantis

Ferramenta utilizada para controle de defeitos na ATS. Através desta ferramenta é possível efetuar o registro de problemas identificados nos processos e no andamento dos projetos. Uma outra visão do Mantis é registrar problemas de componentes.

Url: http://resulthweb.com/mantis

Administração e controle de acesso: Usuário: administrator / Senha: javaroot

[editar] EA

Ferramenta de modelagem UML.

Os arquivos gerados pelo EA, relacionados ao projeto JAVA, ficam na pasta C:\Projeto Java\Documentação\Diagramas (esta pasta é gerida pelo SVN).

Maiores instruções sobre a instalação e utilização do Enterprise Architect podem ser visualizados nesta página.

[editar] Ferramentas de Desenvolvimento

• Spring 3.1.1
• Hibernate 3.6.10
• Hibernate Search 3.4.2
• JasperReports 4.7.1
• JXLS 1.0
• JSF (Mojarra) 2.1.7
• Omnifaces 1.4.1
• Richfaces 4.2.2
• Tomahawk20 1.1.11
• Poi 3.8
• CXF 2.5.1
• Freemarker 2.3.16
• Guava 11.0.2
• Jackson 1.9.5
• Lucene 3.6.1
• JMock 2.5.0
• Log4J 1.2.16
• SLF4J 1.6.4
• XStream 1.3
• Highcharts 3.0.6

[editar] Linhas de Base

As linhas de base serão planejadas a cada projeto e irão conter itens de configuração determinados para cada fase pré-estabelecida.

As linhas de base terão a seguinte nomenclatura:

LB_PRJ9999_N.VV, onde:

• 99999: é o código do projeto no SAC

• N: é o numero da linha de base, e para cada projeto teremos as seguintes:

1- Linha de base do inicio do projeto. Esta linha de base é versionada.

2- Linha de base quando a versão é enviada para o teste de integração. Esta linha de base é versionada e gera um branch, que terá o nome "TESTES". Este branch é descartável, e isto ocorrerá quando a mesma se tornar versão oficial (abaixo).

3-' Linha de base quando é gerado a versão oficial, e que também gera um branch, com a nomenclatura "VERSAO_OFICIAL_PRJ99999". Esta linha de base é controlada, e artefatos só podem entrar nela com autorização, que podem ser um chamado de SLA ou solicitação formal de mudança, feita no SAC. Para ver as instruções de como gerar branch, clique aqui

Para aceitar artefatos na linha de base controlada, deverá ser observado:

1. Se existe um chamado de SLA vinculado aos itens de configuração
2. Se existe uma solicitação formal de mudança, do tipo GCO, pedindo a alteração.

• VV é a versão da linha de base, e será incrementada quando uma for descartada.

[editar] Regras Gerais

• COMITAR OS FONTES TODOS OS DIAS, observando:

1. Não pode haver quebra do teste unitário. Sendo assim, rode ApplicationUnitTestSuite para fazer a verificação.
2. Aplicação deve ser capaz de dar o deploy localmente.
3. Subir partes tangíveis, e completas. Sendo assim, mesmo que a tela já esteja com com os componentes ok (edit's, combobox etc) se não estiver pelo menos incluindo, não subir. Repare que se não estiver alterando ou excluindo pode subir. A função incluir esta ok, neste exemplo.
4. Ao dar checkout nos fontes, colocar o número da tarefa (eventualmente, nas versão estáveis, pode ser uma solicitação formal de mudança, do tipo GCO, feita pelo SAC).

[editar] Merges

Quando a versão for para testes de integração, onde todo o sistema (ou grandes partes do mesmo) é testado, os erros que forem sendo corrigidos, deverão ser feitos nesta versão.

Entretanto, será necessário corrigir os mesmos erros na TRUNK. A técnica a ser utilizada é dar o merge, da versão de testes para o TRUNK, o mais rápido possível, observando as regras gerais acima.

Antes da versão ser oficializada, o gerente de configuração deve verificar se todos os merges foram feitos. (completar com Haroldo).

[editar] Verificação dos Merges

(completar com Haroldo).

[editar] Procedimentos de Backups

[editar] Itens de Configuração

Abaixo estão listados os itens de configuração do processo GCO, que passarão por auditoria.

[editar] Liberação de Versões

[editar] Liberação de Versão SLA

A sequencia de atendimento dos SLA´s, do sistema Web é a seguinte:

1. Suporte abre SLA, e o departamento de sistemas faz a correção dentro dos prazos acordados
2. CQ faz o teste funcional
3. Programador faz o teste unitário ou justifica a sua ausência.
4. A tarefa estando aprovada, comita os fontes e coloca a tarefa no usuário "Versão estável JAVA" (código deste usuário é 818), e avisa por e-mail o responsável por gerar versão.
5. Responsável por gerar a versão, compila e comita a versão no subversion. Neste momento a tarefa deve ser fechada.
6. Suporte pega a versão, agenda a troca pelo painel, e fecha o atendimento.