Archive for the ‘suporte técnico’ Category

Preparação de um servidor de aplicação versus máquinas virtuais com servidores de aplicação prontos para uso (parte 1)

2 Comments »

A virtualização de servidores traz algumas vantagens bastante interessantes:

  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.


Treinamento de Gerência de Configuração de Software em São Paulo em janeiro de 2009

No Comments »

Acontecerá em São Paulo, em janeiro de 2009, a próxima turma do curso de Gerência de Configuração de Software com Ferramentas Open Source Trac e Subversion.

É um curso extenso. São 32 horas de treinamento necessárias para cobrir com profundidade o processo e a operação das ferramentas de forma a resolver completamente o problema de Gerência de Configuração de Software de sua equipe de desenvolvimento.

Para mais informações sobre preço, local e inscrições, consulte os links a partir do calendário de eventos:

Faça já sua inscrição! Vagas limitadas!


“Merge” do curso de Administração de Ferramentas de GCS e do módulo GCS Avançado

No Comments »

Faz algum tempo que não oferecemos o treinamento do módulo de Administração de Ferramentas de GCS em turmas abertas; o módulo vinha sendo oferecido apenas para treinamentos in company.

Após algumas reorganizações, decidimos mesclar o módulo de Administração ao módulo GCS Avançado, que agora passa a ter 16hs. O treinamento completo em Gerência de Configuração de Software passa então para 32hs. É extenso, mas necessário para cobrir com profundidade os tópicos propostos.

Visite a página do curso de Gerência de Configuração de Software para mais detalhes sobre o novo programa.


Novos planos de suporte técnico para Gerência de Configuração de Software

No Comments »

Durante as atividades de Gerência de Configuração de Software (GCS), podem acontecer algumas situações em que é necessário um conhecimento mais especializado para resolver o problema. Como o desenvolvimento do software não deve parar, é importante ter um serviço de suporte técnico para garantir a operação contínua e correta das ferramentas e também do processo de GCS.

A Pronus oferece esse suporte especializado em Gerência de Configuração de Software, particularmente nas ferramentas Subversion e Trac.

São dois planos de suporte (trimestral e anual) com um conjunto de horas técnicas pré-contratadas que podem ser usadas durante o período de validade do plano para manter e aprimorar a área de GCS da sua empresa. Veja mais detalhes na página do serviço de suporte.


Acertando o formato de data do Trac

No Comments »

Uma das várias funcionalidades interessantes que o Trac oferece, além do próprio controle de mudança (que é fundamental para a Gerência de Configuração de Software), é o relatório dos eventos por data, o timeline. Entretanto, muitas vezes a data é apresentada no formato americano (MM/DD/YYYY) e não no formato que usamos aqui no Brasil (DD/MM/YYYY).

A boa notícia é que é muito simples acertar isso. O que define o formato de apresentação de data usado pelo Trac é o Locale configurado no servidor. Sendo assim, basta mudar o Locale para que o formato fique no formato desejado.

Uma das maneiras de fazer isso é configurar uma variável de ambiente do Apache. No Debian, basta acrescentar a seguinte linha no arquivo /etc/apache2/envvars:

export LC_ALL=pt_BR.UTF-8

Não esqueça de pelo menos fazer o reload do Apache depois.