Entrega Contínua com Ruby on Rails, GitHub, Code Climate, Travis CI e Heroku

Não se espante com a quantidade de tecnologias que o título do artigo expõe, pois é apenas a linha de frente de um arsenal de ferramentas que executam nos bastidores de cada plataforma. O que veremos a seguir é apenas um passo a passo de como podemos implementar um ambiente automatizado para publicar uma aplicação na web, de ferramentas muito utilizadas na comunidade Open Source mas que algumas pessoas ainda não conhecem.

Entrega Contínua

No livro Entrega Contínua – Como Entregar Software de Forma Rápida e Confiável, Jez Humble e David Farley falam do objetivo como profissionais de desenvolvimento, que é de entregar software útil e funcional aos usuários o mais rápido o possível. Os autores citam alguns antipadrões comuns de entrega de versão como:

• Implantar software manualmente
• Implantar em um ambiente similar ao de produção somente quando o desenvolvimento estiver completo
• Gerência de configuração manual dos ambientes de produção

Eles descobriram que para alcançar o objetivo da Entrega Contínua – tempo de ciclo curto e alta qualidade – precisamos entregar versões frequentes e automatizadas de nosso software. A entrega rápida também é importante porque permite que você descubra quais correções e funcionalidades implementadas de fato são úteis. Para mais detalhes, acesso o recurso Entrega Contínua.

Controle de versão em banco de dados com migrations

O desenvolvimento de aplicações em três camadas praticamente tornou ubíqua a persistência de dados em sistemas gerenciadores de bancos de dados. Durante o desenvolvimento, enquanto alterações em artefatos de código-fonte geralmente são controladas com algum sistema de versionamento, alterações em bancos de dados quase nunca são controladas.

Ao codificar, de tempos em tempos o desenvolvedor disponibiliza alterações nos arquivos em que está trabalhando para um repositório. Com artefatos versionados é possível se ter um controle sobre todas as alterações feitas em um dado arquivo, conferir as diferenças entre versões distintas e até retornar arquivos à como seu conteúdo se encontrava num dado momento no passado. Isso tudo além, é claro, de se viabilizar o trabalho concomitante de várias pessoas num mesmo projeto.

Num cenário típico, imagine que um desenvolvedor esteja trabalhando numa dada funcionalidade. Ele codifica, submete alterações ao repositório, codifica novamente. Então o desenvolvedor percebe que será preciso incluir uma nova coluna numa das tabelas no banco de dados. O desenvolvedor então acessa o SGBD e realiza diretamente a adição da coluna na tabela.

Perceba que, enquanto um arquivo de código-fonte evolui por alterações que são controladas (i.e., sabe-se quem fez, quando fez, e até se não era necessária pode-se sempre voltar facilmente à versão anterior), geralmente as alterações feitas em banco de dados não. Por mais metódico que seja o desenvolvedor com respeito às alterações a serem feitas em bancos de dados, no fim das contas sempre há a necessidade de se informar verbalmente a alguém sobre a execução de tais alterações. Vê-se isso muito claramente especialmente quando há mais de um ambiente de banco de dados e surgem as perguntas: Aquela alteração já foi replicada no outro ambiente?

Resumidamente, pode-se dizer que migrations é uma maneira de realizar alterações em um banco de dados de forma organizada e controlada. Trata-se de uma técnica muito comum no desenvolvimento em ambientes modernos de programação, como Ruby on Rails ou CakePHP, por exemplo.

Agilidade em Série – XP – Integração Contínua

No 3º episódio da temporada de Extreme Programming, Adriano Ohana fala sobre Integração Contínua de uma maneira um tanto quanto perigosa, digamos. O nível de adrenalina deverá aumentar a cada seção do artigo. Portanto, não diga que não avisamos 🙂

Boa leitura a todos.

Agilidade em Série – XP – Integração Contínua