- Governança-TIC
- 01. Estrutura do DTIC e Comitês
- 02. Estratégia de TIC
- 03. Indicadores e Metas de TIC
-
04. Processos de TIC
-
1.01. Contratação de STIC
-
1.02. Processo do PETIC
-
1.03. Processo do PDTIC
-
1.04. Capacitação de TIC
-
1.05. Processo do PAT
-
1.06. Orçamentos de TIC
-
2.01. Gestão de Demandas TIC
-
2.02. Gestão de Projetos TIC
-
2.03. Gestão de Contratos TIC
-
3.01. Gestão de Riscos TIC
-
3.02. Continuidade de Serviços TIC
-
3.03. Processo de Eventos TIC (Monitoria)
-
3.04. Processo de Backup / Restore
-
4.01. Desenvolvimento de Software
-
Matriz de Artefatos MDS
-
Diretrizes Desenvolvimento de Software
- Arquitetura de Desenvolvimento Java
-
Modelo Conceitual de Classes
-
Modelo de Atividades
- Modelo de Banco de Dados
-
Modelo de Caso de Uso
- Modelo de Classes
-
Modelo de Componentes
-
Modelo de Implantação
-
Modelo de Instâncias
-
Modelo de Interação
-
Modelo de Máquina de Estados
- Padrão de Interface Web de Sistema com o Usuário
- Orientações de trabalho Desenvolvimento de Software
-
Diretrizes Desenvolvimento de Software
-
Matriz de Artefatos MDS
-
4.02. Sustentação de Software
-
5.01. Central de Serviços TIC
-
5.02. Gerenciamento de Problemas TIC
-
5.03. Gerenciamento de Mudanças TIC
-
5.04. Gerenciamento de Liberação e Implantação TIC
-
5.05. Gerenciamento de Configuração e Ativo de Serviços TIC
-
5.06. Gerenciamento do Catálogo de Serviços TIC
-
5.07. Gerenciamento de Nível de Serviço TIC
-
6.01. Pesquisa Satisfação Usuários de TIC
-
6.02. Organizar Reuniões de TIC
-
Ferramentas para Mapeamento de Processos de TIC
-
sobre Processo de TI
-
1.01. Contratação de STIC
- 05. Segurança de TIC
- 06. Portfólio de TIC
-
Base de Conhecimento
- Capacitação de TIC
-
Normativos CNJ
-
Normativos DTIC
- Publicações de TIC
-
Rede sem fio (Wi-Fi)
-
Relatório Atividades DTIC
- Videoconferência
Melhorar a qualidade, organizar e facilitar o deploy das aplicações JEE pelas equipes
Basicamente este novo modelo define a princípio três ambientes distintos e interdependentes onde será possível realizar o deploys das aplicações para integração, homologação e produção.
Como pré-requisito as aplicações deverão ter versões estáveis (tags) geradas para cada ambiente de deploy solicitado no controle de versão na ordem e em horários pré-definidos para realizar os deploys previamente planejados e agendados como descrito a seguir:
- integração contínua (a cada commit): realizar o build e testes automatizados do projeto para verificar sua integridade antes de geração/liberação de uma versão.
- ambiente de desenvolvimento (tags/dev/x.x.x): responde pelo nome portal-dev, poderá realizar deploys a cada hora. A finalidade deste ambiente é realizar testes de integração das aplicações antes da homologação pelo usuário. Sugere-se, porém, que sejam realizados testes com o o servidor de aplicações localmente para simular este ambiente e/ou caso problemas sejam encontrados por causa da diferença de ambiente entre os servidores utilizados localmente (webservers Jetty e Tomcat) e nos ambientes (appserver Glassfish).
- ambiente de homologação (tags/tst/x.x.x): responde pelo nome portal-tst, poderá realizar deploys a cada hora. O seu objetivo é disponibilizar as aplicações para serem homologadas pelos usuários finais e/ou responsáveis pelas aplicações simulando o ambiente de produção.
- ambiente de produção (tags/prd/x.x.x): responde pelo nome portal.tjpr.jus.br, poderá realizar até um deploy a princípio antes do horário de expediente durante a madrugada (05:00).
O deployer-dev - Hudson CI, é a ferramenta responsável por realizar os deploys agendados automaticamente através da criação de tags como descrito logo acima e também por realizar a Integração Contínua (CI - Continuous Integration) das aplicações a cada commit realizado.
Abaixo um screenshot da ferramenta citada demonstrando as 4 abas para a configuração dos projetos para cada caso descrito anteriormente.
ambiente de desenvolvimento