O curso aborda o uso das ferramentas para atender às necessidades de Gerência de Configuração de Software. São mais de 60 exercícios práticos guiados por um processo que define um fluxo de trabalho correto de operação das ferramentas. O programa completo se encontra na página do curso. Faça sua reserva online agora mesmo!

Cada aluno terá um repositório próprio do Trac/Subversion, apostila e também recebe uma máquina virtual pré-configurada pronta para uso no projeto de sua equipe.

Veja mais informações na página do curso.

Faça já sua reserva! Aproveite os descontos para duas ou mais inscrições.

A primeira PronusBox contém o Trac como controle de mudança e o Subversion como controle de versão. A segunda PronusBox disponível usa o Redmine para controle de mudança e o Subversion e o Mercurial como opções de controle de versão centralizado e distribuído respectivamente.

A proposta é cobrar por cada máquina uma fração do valor em horas técnicas que seriam usadas para a instalação e configuração de um servidor a partir do zero. Com uma estimativa bastante otimista de 60 horas técnicas para a preparação de um servidor equivalente, o preço de cada PronusBox varia entre R$ 300 e R$ 350.  Como promoção de lançamento, neste mês de janeiro, oferecemos um desconto de 28,5% por cada PronusBox. Aproveite!

O desfecho poderia ter sido outro, mais  simples e rápido. O começo seria igual, com Roberval recebendo a incumbência de instalar o servidor com Redmine e Mercurial. Porém, ao invés de preparar um servidor, prefere procurar uma solução pronta. Como os servidores da empresa já usam virtualização, então o ideal seria uma máquina virtual pré-configurada com as aplicações desejadas que pudesse ser baixada, instalada sem maiores dificuldades.

Uma procura rápida no Google com os termos “máquina virtual redmine mercurial” mostra um resultado bastante interessante logo na primeira opção. A especificação da PronusBox (a máquina virtual encontrada) descreve em detalhes a configuração existente e alguns procedimentos administrativos como criação de projetos e backup. Não há dúvida: é essa mesma.

O passo seguinte é conseguir a verba para aquisição.  Como o pedido de instalação já havia sido aprovado, a verba para aquisição da máquina virtual foi liberada sem maiores dificuldades. Além do mais, o preço é irrisório.

O que demorou mais tempo foi baixar os 750 MiB da máquina virtual. Depois disso, conforme esperado, a instalação foi simples e o serviço estava no ar. Ao invés de duas semanas preparando um servidor, tudo pronto em menos de um dia! Chefe contente e  desenvolvedores satisfeitos.

1. Otimização dos recursos disponíveis. O mesmo servidor físico pode ser multiplicado em vários servidores virtuais, economizando equipamento e energia.
2. Independência de plataforma. Uma máquina virtual pode conter um sistema operacional diferente da máquina hospedeira.
3. Flexibilização através de Máquinas Virtuais. Podem ser instaladas, trocadas, congeladas, salvas e até mesmo adquiridas prontas para uso com facilidade.

A aquisição de uma máquina virtual com um servidor de aplicação costuma ser extremamente viável. Afinal, preparar um servidor de aplicação é trabalhoso e complicado. Entender as aplicações desejadas, descobrir as dependências, pesquisar e testar alternativas de configuração e analisar os resultados é bastante demorado, chegando facilmente a semanas de trabalho.

Uma caso possível (baseado em fatos reais):

“Robervaldo faz parte da equipe de administração de redes de uma empresa. Em uma segunda-feira qualquer, chega ao serviço e recebe a notícia que precisa preparar um servidor com o Redmine e o Mercurial (pra ontem, claro). Sem fazer a menor ideia do que sejam essas aplicações, só lhe resta recorrer ao Google. Descobre que Redmine é uma aplicação web para gerenciamento de projetos feita em Ruby on Rails e que Mercurial é uma ferramenta de controle distribuído de versão. O próximo passo é instalar.

Quase tão ruim quanto não achar nenhuma solução é achar dezenas delas. No site do Redmine existem várias e várias sugestões de como fazer a instalação em diversos sistemas operacionais e versões. Nenhuma dessas receitas é ‘oficial’, feita por membros do projeto; são todas feitas por colaboradores externos com diferentes graus de conhecimento da ferramenta. Algumas receitas estão claramente desatualizadas, mas continuam listadas no site. Outras recomendam passos e pacotes diferentes para instalação. Qual é a melhor maneira? O jeito é experimentar.

Robervaldo instala a versão mais nova do Ruby, mais a versão X do pacote tal e assim por diante. Mas opa! O Redmine na versão Y não funciona com o pacote tal na versão X nem com o Ruby mais atual! E agora? Desinstala tudo e começa de novo? A instalação bagunçou outros aplicativos que estavam instalados antes? Formata, ué.

Tem de escolher um tipo de banco de dados. Mas qual? Postgres? MySql? Sqlite3? Uni-duni-tê…

Passados três dias, depois de aprender que o teste de instalação deve ser feito em uma máquina virtual, usando snapshots, o Redmine parece estar funcionando. A próxima instalação é a do Mercurial.

Parece mais fácil. Poucas opções. Exe ou msi? Precisa ou não do TortoiseHg? Qual Python 2.X? Salamê-minguê…

Ah… não é só instalar, tem de publicar os repositórios pela rede. HTTP? SSH? NFS? Sorvete-colorê…

Uma semana se passou e o chefe em cima, cobrando. Robervaldo anda pelo corredor e os desenvolvedores que esperam o servidor olham torto. A demora deixa todo mundo tão irritado que nem a mulher do café o cumprimenta mais.

Mais dois dias. Acabou? Quase. Falta juntar o Redmine com o Mercurial. Robervaldo encontra um artigo promissor sobre integração dos dois. Epa! De 2009??? Funciona ainda? Outro link para autenticação do Apache pelo MySql. Também de 2009??? Mas e agora, Roberval, se você usou Postgres? Planos par ao fim de semana são cancelados…

Mais três dias e tudo entregue. Fim da história!?!

Epílogo: Duas horas tranquilas depois da entrega do servidor e o telefone toca. Coisa boa não deve ser:

- Roberval, o pessoal quer que o Redmine crie automaticamente os repositórios, precisa também fazer um script de backup e, aproveitando, dá uma olhada em como fazer blá blá blá…”

Mas tudo isso poderia ser mais simples. No próximo artigo, vamos abordar como a aquisição de uma máquina virtual economiza dinheiro e tempo, além de fornecer um servidor tecnicamente mais bem preparado.

As ferramentas de controle de mudança até possuem funcionalidades que exibem o histórico e o conteúdo das revisões contidas no controle de versão. Entretanto, para a GCS, o que é realmente necessário é uma amarração entre o pedido de mudança e a revisão em que está implementada e vice-versa, permitindo rastrear a solicitação até sua implementação e o caminho contrário.

No controle de versão, essa ligação é feita no momento da consolidação (commit) através da mensagem de log, onde se registra um padrão tal como “resolve #173″, que indica o ticket finalizado. Do lado do controle de mudança, a amarração correspondente é feita adicionando um comentário ao ticket/tarefa com um padrão parecido —”implementado em [238]” por exemplo —, e depois mudando o estado do ticket/tarefa para ‘fechado’ (ou outro estado, conforme o ciclo de vida definido).

O registro na mensagem de log da consolidação é manual, mas o comentário adicional no ticket pode ser feito automaticamente. No Redmine, por exemplo, ao encontrar o padrão específico na mensagem de log de uma revisão, o ticket associado é fechado imediatamente.

O problema do registro manual na mensagem de consolidação é que um desenvolvedor desatento ou despreparado pode simplesmente não usar o padrão definido. O ideal é que haja algum tipo de validação que pelo menos exija a amarração a um ticket, mas outras checagens podem ser feitas, tais como se o ticket realmente existe, está aberto e pertencente ao autor do commit. No Subversion, essas validações podem ser feitas através de um script de pre-commit.

O script de pre-commit abaixo faz uma validação mínima, exigindo que o padrão referenciando um único ticket ou tarefa exista em toda mensagem de consolidação:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31

#!/usr/bin/python
# -*- coding: utf-8 -*-
#
# Copyright (c) 2011 Pronus Engenharia de Software
# Copyright (c) André Felipe Dias
# Licensed under the MIT license:
# http://www.opensource.org/licenses/mit-license.php
# ----------------------------------------------------------------------------------

import re
import sys
from  subprocess import Popen, PIPE

repos_path = sys.argv[1]
transaction = sys.argv[2]
svnlook = '/usr/bin/svnlook'
log = Popen(
           (svnlook, 'log', '-t', transaction, repos_path),
           stdout=PIPE, stderr=PIPE,
           stdin=PIPE
           ).communicate()[0].lower().strip()
padrao = re.findall('(?:ref|refs|resolve|implementa)\s+(#[0-9]+)', log)
tickets = re.findall('#\d+', log)
if not padrao:
    sys.exit(''' Padrao nao encontrado. Sao mensagens de log validas:
 ref #123
 resolve #123
 implementa #123''')
elif len(tickets) > 1:
    sys.exit('So deve haver referencia a um ticket/tarefa por consolidacao')
sys.exit(0)

Nos links abaixo, há outros exemplos de scripts de commit que podem servir de inspiração para validações mais avançadas:

1. http://trac.edgewall.org/browser/trunk/contrib
2. http://svn.apache.org/repos/asf/subversion/trunk/contrib/hook-scripts/

Python ainda é uma linguagem que se usa por opção e não imposição. Como foi bem descrito neste artigo:

Eu não escuto as pessoas dizerem “Eu uso Python no trabalho porque eu tenho de usar, mas eu preferia estar programando em Java!” Mas frequentemente escuto as pessoas dizerem que gostariam de usar Python no trabalho se pudessem.

O TortoiseHg continua seguindo os lançamentos do Mercurial e, nesta versão, além de acompanhar as mudanças da versão 1.7 do Mercurial também faz algumas pequenas correções. A lista está disponível aqui.

São Paulo – SP:

• Módulo Básico: 07 e 08 (manhã) de junho de 2010
• Módulo Avançado: 08 (tarde) e 09 de junho de 2010

Brasília – DF:

• Módulo Básico: 14 e 15 (manhã) de junho de 2010
• Módulo Avançado: 15 (tarde) e 16 de junho de 2010

As reservas podem ser feitas através do formulário de inscrição.