Árvore de páginas

Versões comparadas

Chave

  • Esta linha foi adicionada.
  • Esta linha foi removida.
  • A formatação mudou.

Página destinada a detalhar as particularidades do TAF nos processos corporativos ( expedição, manutenção e inovação )

Índice
Índice

Expedição

Este tópico tem como objetivo detalhar a expedição do TAF, tanto no processo de manutenção quanto no processo de inovação.

 

Particularidades no macro processo de inovação:

1. Durante o ciclo de construção, os chamados de Legislação e os requisitos de Inovação serão desenvolvidos e homologados na branch de Inovação;
2. As alterações de fontes, autocontidas e layout deverão ser realizadas nos diretórios de Inovação;
3. As alterações de dicionário deverão ser realizadas no ATUSX ( em pacote individual ) e incorporados no final do release de expedição;
4. Os pacotes do ATUSX sempre devem ser criados abaixo do Projeto do Release de entrega da versão 12;
5. Assim que o chamado/requisito for homologado na versão 11, deve ser solicitado ao GCAD que faça a incorporação no Projeto TAF Segregado ( utilizado para atualização do TAF na versão 11 );
6. Assim que o chamado/requisito for homologado na versão 12, este automaticamente será incorporado ao Release “pai” para expedição.
7. Os requisitos/chamados da versão 11 devem obedecer o Calendário do TAF;
8. Os requisitos/chamados da versão 12 devem obedecer o Calendário do Release Incremental.

 

Particularidades no macro processo de manutenção:

1. Durante o ciclo de construção, os chamados de Não Conformidade serão desenvolvidos e homologados na branch de manutenção.
2. Quando chamado na versão 11, as alterações de dicionário deverão ser realizadas no UPDTAF quando não contemplado pelo UPDDISTR*.
*Detalhes sobre as regras do UPDDISTR:

 

Fluxo operacional:

Image Modified

 

 

Manutenção ( devido as mudanças no processo do release incremental este tópico está sendo reavaliado )

Os códigos fontes do TAF estão armazenados em um único diretório no TFS. Qualquer manutenção nas rotinas, independente da versão do TAF ( 11 ou 12 ), devem ser realizadas nesse único diretório.

Após a homologação do chamado, as alterações serão compiladas em 4 diretórios distintos:

1) D-1 Protheus Padrão - Versão 11 ( todas as línguas e bases );

2) D-1 Protheus Padrão - Versão 12 ( todas as línguas e bases );

3) D-1 TAF - Versão 11 ( todas as línguas, base TOPCONNECT );

4) D-1 TAF - Versão 12 ( todas as línguas, base TOPCONNECT ).

Todo chamado da versão 11 deverá gerar uma réplica para a versão 12. Como o fonte já foi corrigido na versão 11 e este se aplica à todas as versões, a FNC réplica da versão 12 deverá ser encerrada apenas com os fontes corrigidos amarrados como dependência no pacote. Deverá ser colocada uma observação no encerramento da FNC, indicando o chamado original que aquele erro já foi corrigido.

 

Versão12
1 - Chamado envolve alteração de dicionário
  • Fonte: Alterar na branch de Inovação do Release Corrente
  • Dicionário: Alterar apenas no ATUSX - Pacote MANUTENÇÃO do Release corrente
2 - Chamado não envolve alteração de dicionário
  • Fonte: Alterar na branch de Manutenção
3 - Chamado envolve alteração de tabela autocontida
  • Tabela Autocontida: Alterar na branch de Inovação do release corrente
  • Regra: A tabela autocontida sofrerá manutenção através de uma legislação, e consequentemente entrará no processo de inovação ( item 1 ).
  • Exceções ( apenas em casos críticos ): Alterar na branch de manutenção com uma sub-versão, exemplo: autocontidasv100301.taf.
  • Devem ser alterada a versão apenas dos .dbf que sofreram manutenção. Os demais mantem a versão.
4 - Chamado envolve alteração no layout.def / dbf / dtc
  • Layout: Alterar na branch de Inovação do release corrente
  • Regra: O Layout sofrerá manutenção através de uma legislação, e consequentemente entrará no 
    processo de inovação ( item 1 ).
  • Exceções ( erros ): Criar uma sub-versão na seção de "build" do layout dentro do layout.def
  • Observação: Criar uma seção de versão dentro do layout.def ( formato: versão + sub-versão + data ) exemplo: 2.600120150626
  • Criptografar arquivo layout.def ( + interface que descriptografa o arquivo para visualização )
Versão11
1 - Chamado envolve alteração de dicionário
  • Fonte: Alterar na branch de manutenção
  • Dicionário: Alterar o UPDTAF ( UPDDISTR não executa o RUP_ na versão 11 )
  • Observação: Alterar o manual de atualização orientando a execução do UPDTAF que primeiro executa o UPDDISTR (automático) e depois o UPDTAF.
  • Documentar todas as alterações no boletim ( TDN ).
  • Criar uma trava no UPDATE, só pode ser executado na versão 11 ( quando o diretório único estiver em produção ) verificar o nome da função genérica.
2 - Chamado não envolve alteração de dicionário
  • Fonte: Alterar na branch de Manutenção
3 - Chamado envolve alteração de tabela autocontida
  • Tabela Autocontida: Alterar na branch de Inovação do release corrente
  • Regra: A tabela autocontida sofrerá manutenção através de uma legislação, e consequentemente entrará no processo 
    de inovação ( item 1 ).
  • Exceções ( apenas em casos críticos ): Alterar na branch de manutenção com uma sub-versão, exemplo: autocontidasv100301.taf.
  • Devem ser alterada a versão apenas dos .dbf que sofreram manutenção. Os demais mantem a versão.
4 - Chamado envolve alteração no layout.def / dbf / dtc
  • Layout: Alterar na branch de Inovação do release corrente
  • Regra: O Layout sofrerá manutenção através de uma legislação, e consequentemente entrará no 
    processo de inovação ( item 1 ).
  • Exceções ( erros ): Criar uma sub-versão na seção de "build" do layout dentro do layout.def
  • Observação: Criar uma seção de versão dentro do layout.def ( formato: versão + sub-versão + data ) exemplo: 2.600120150626
  • Criptografar arquivo layout.def ( + interface que descriptografa o arquivo para visualização )

 

Alterando o dicionário

...

Image Added

 

...

Image Added