Ambiente de Desenvolvimento

Este documento descreve um Ambiente de Desenvolvimento genérico, baseado nas soluções FOSS relacionadas directamente com o desenvolvimento de software. Edite-o apenas quando possa contribuir muito significativamente para a melhoria e correcção do seu conteúdo. Caso pretenda somente discutir acerca do seu conteúdo, usa o documento de discussão correspondente.

O desenvolvimento e manutenção de soluções informáticas implica a implantação de diversos ambientes de trabalho:

• Ambiente de Desenvolvimento (DEV): este ambiente lida com os incidentes e revisões realizadas à solução informática. É o ambiente com a versão mais recente da solução, mesmo que não esteja estável, na qual se realizam todos os processos de codificação: desenvolvimento, manutenção correctiva ou manutenção evolutiva.
  Domain: http://dev.<domain>.off.
• Ambiente de Testes (TST): este ambiente lida com os testes às entidades, com os testes de integração e com os testes de certificação das especificações face aos requisitos impostos à solução informática. É o ambiente com a versão estável mais recente da solução, e pode também ser usado como ambiente de demonstração das funcionalidades dessa solução. Replica ao máximo o ambiente de produção, devendo serem periodicamente sincronizados entre si.
  Domain: http://dev.<domain>.lan.
• Ambiente de Produção (PRD): este ambiente tem a versão mais estável de todas, e impõe imensas restrições ao acesso à informação, por questões de segurança. A disponibilidade deste ambiente é a máxima possível, devendo ser acessível 24 horas por dia 7 dias por semana ao longo de todo o ano. A migração da versão estável mais recente deve implicar o menor impacto possível na disponibilidade deste sistema, e só deve ser realizada quando as novas funcionalidas ou correcções são realmente necessárias.
  Domain: http://<sub-domain>.<domain>.<tld>.

Nota: estes ambientes não implicam necessariamente a disponibilização de um servidor dedicado por cada um dos ambientes. Podem existir todos no mesmo servidor, desde que sejam mantidos as condições de serviço essencias à função de cada ambiente. É no entanto comum encontrar-se pelo menos dois servidores: um com o ambiente de desenvolvimento e outro com o ambiente de produção, designados por servidor do ambiente offline e servidor do ambiente online.

Desenhar o diagrama da arquitectura.

A arquitectura do ambiente de desenvolvimento deve disponibilizar as seguintes soluções:

• Sistema de gestão de incidentes;
• Sistema de controlo de versões;
• Sistemas de colaboração;
• Ferramentas de desenvolvimento de software.

Terá que também permitir a fácil ligação entre os sistemas:

• O sistema de controlo de versões associa uma dada revisão ao incidente que despoletou as necessárias alterações;
• O sistema de controlo de versões associa uma dada revisão ao documento técnico, elaborado de forma colaborativa, que descreve as alterações com mais pormenor;
• O sistema de gestão de incidentes associa um dado incidente à revisão que o resolveu;
• O sistema de gestão de incidentes associa um dado incidente ao documento técnico, elaborado de forma colaborativa, que descreve o incidente com mais pormenor;
• A documentação técnica associa um dado incidente com a revisão que o resolveu, associa uma revisão aos incidentes por ela resolvidos, registra o histórico da evolução das funcionalidades, dos levantamentos de requisitos, das análise de impacto, das especificações funcionais, dos testes realizados, etc.
• A documentação com base nos comentários existentes no código-fonte, automaticamente gerada após cada nova revisão da solução, deve também indicar qual o incidente e qual o documento técnico relacionado com as alterações efectuadas.

• Ser um ambiente de desenvolvimento fluído, simples e prático.
• Manter um histórico das alterações/modificações ao código-fonte ou à estrutura da base de dados.
• Manter um histórico dos incidentes do projecto: sejam Bug Requests, Feature Requests, Support Requests ou Patches.
• Manter a documentação técnica actualizada.
• Usar ferramentas Open-Source, que não causam dependências fechadas a sistemas proprietários e que podem ser facilmente adaptadas às necessidades dinâmicas da equipa.
• Receber notificações de alterações e novos eventos através de canais RSS. Os eventos podem ser incidentes (novos, mudança de estado, fechados, …) ou alterações a documentos no SiteWiki.
• Reportar novos incidentes através de correio electrónico, além de acesso Web.

As etapas a cumprir dividem-se entre servidor e clientes.

Assume-se que o Apache, MySQL, PHP, Perl, Python e Tcl/Tk estão já instalados:

• Instalar o Subversion 1.1.2.
• Instalar o WebSVN 1.61.
• Instalar o Mantis 0.19.2.
• Instalar o DokuWiki 2005-01-16.

• Instalar o Subversion 1.1.2.
• Instalar o TortoiseSVN 1.1.2.
• Aprender os procedimentos de desenvolvimento, em conjunto com as Best-Practices:
  • Controlo de Versões: checkout, change, update/merge, test, commit, export, …
  • Gestão de Incidentes: abrir incidente, actualizar incidente, fechar incidente, …
  • Documentação Técnica.
  • Documentação do Utilizador.