Diversão de Domingo com Python

Utilizo muito os serviços do DeployBot para CD, junto ao meu fluxo de CI. Mas nem como em alguns momentos deploy é apenas uma questão de estratégia, é chato ficar ter que abrindo o navegador para acessar o painel do DeployBot a todo momento para acionar um build.

Então, juntando a minha vontade de estudar mais Python e minha mania incansável de ficar criando ferramentas sempre que descubro que algo que uso possui uma API, nasceu o deploybot-cli, uma pequena ferramenta de linha de comando, para interagir com a API do DeployBot.

Você pode baixar o pacote - ou o fonte diretamente do Github, ou mesmo instalar via Pip:

pip install deploybot-cli

No momento que escrevo este post, a última versão estável é a 0.2.3, mas tão logo os estudos forem avançando, vou melhorando, fique de olho.

Claro, fique a vontade para utilizar somente as classes e integrar da forma que achar melhor com sua aplicação ou ambiente.

O projeto é pequeno e para mim, é apenas uma forma de estudar mais uma linguagem e também de agilizar meu trabalho.

Fique a vontade para mandar um PR com melhorias (principalmente no cli.py) ou dicas de como melhorar a ferramenta. A API é bem limitada e possui poucos end-points, mas para mim, é extremamente útil.

Um grande abraço!

Vamos falar de refatoração

Ou porquê você deveria fazer seu trabalho direito

Tem muito tempo que o que mais ouço são “programadores” reclamando que tal biblioteca não faz, tal componente é bugado demais, framework x é mal feito por causa disso e daquilo… sempre que me pego no meio de um papo desses, lanço duas frases:

  • Muito mimimi e pouco pull request.
  • Porque você não arruma o código que te incomoda?

Porque programadores habilidosos, simplesmente não se mexem e arrumam o que está com problema ao invés de apenas reclamar ou citar mais problemas?

A resposta básica é de que o código legado não tem testes, não foi projetado pensando nisso e não tem como colocar. Pra mim isso é balela, sempre tem!

Muitos times também largam que “nós vamos rescrever a aplicação, na próxima versão vamos fazer direitinho seguindo as melhores práticas”, admita, isso nunca vai acontecer. Simplesmente porque você sempre vai pegar o máximo de tempo disponível simplesmente para arrumar os bugs da versão atual ou adicionar novas funcionalidades - sem testes, copiando e colando as mesmas gambiarras que “já funcionam” em outras partes da aplicação. Pode ser que isso até aconteça, então, o time se divide em dois grupos: o que vai manter a versão nova e o que irá prestar manutenção na antiga até que a nova seja lançada. O resultado disso é: a versão antiga, começa a ficar cada vez maior, consequentemente, com mais problemas, e o time que a está mantendo, cada vez mais desanimado e extressado, seja pelo excesso de problemas que acontecem ao mexer em determinadas partes do software, cujos efeitos colaterais são totalmente inesperados, quanto pela vontade de estar participando na nova versão do projeto, que parece ser “bem mais legal e menos extressante”. Neste tumulto, rolam muitas trocas de membros entre os times, para resolver inúmeras urgências e acabamos com dois projetos atrasados e um time completamente desmotivado.

Existe também um outro cenário, o da refatoração de código, seja ela para seguir num novo padrão ultra bacana que o time viu na internet e que funciona com empresa tal. Mas lembre-se: Refatoração sem teste é apenas manutenção - de risco - de código legado.

Então, antes de tudo, tente ao máximo fugir desses dois cenários apresentados, sua aplicação - e sua sanidade - agradecem.

Muitos pensam que adicionar testes em uma aplicação, é do dia para a noite, criar testes de integração, unitários, comportamentais, etc e logo terá 100% de cobertura do código; mas vamos com calma pequeno gafanhoto…

Começar a cobrir uma aplicação com testes deve ser feito com calma, paciência e principalmente, por partes. Por exemplo: vai refatorar um componente ou uma tela? Porque você não apenas escreve um teste de comportamento para aquela tela? Vamos imaginar que esta tela seja um formulário, com dois campos: nome e email, e dois botões, um de submit, e outro de reset. Nosso cenário de teste é simples:

  • acessar a rota do formulário e verificar se o mesmo existe
  • preencher os campos com dados inválidos e verificar se ao clicar em submit, o mesmo terá sua validação recusada
  • preencher os campos novamente, desta vez, com dados válidos, clicar em submit e verificar se a mensagem de sucesso é exibida
  • preencher o formulário, clicar em reset e verificar se os campos foram limpos.

Simples não? Em poucos minutos, você escreveria este cenário (protractor, selenium, webtest,cucumber, tanto faz) e garantirá que a tela está funcionando. Testes unitários, mocks, stubs? Esqueça isso, em outro momento, quando você for mexer em algum componente, que isso possa ser encaixado, você o faz. Sobrou tempo? Porque não escrever um teste unitário para este controlador então? E assim vamos, a cada interação um teste.

Vamos imaginar outro cenário, uma aplicação simples, MVC, onde você descobriu um bug que precisa ser corrigido urgentemente, após uma sessão de debug, você descobriu que o problema está em um dos models utilizados. Agora temos o ambiente perfeito para nosso teste unitário. Porque não, ao corrigir o bug, você não escreve um teste para este model e cobre o bug que foi corrigido? Aplicando um cenário de aceitação e outro de erro, para garantir o comportamento do mesmo.

Como podemos ver, iniciar testes em uma aplicação existente não é impossível e nem um bicho de sete cabeças, requer apenas paciência e uma dose de bom senso sobre o que testar em cada momento, você vai ver que com o passar do tempo, sua aplicação terá cada vez mais cenários e uma cobertura de testes crescente, onde a equipe se tornará cada vez mais confiante em manter aquele “código legado” onde todos antes tinham medo de pôr as mãos.

Para finalizar, deixo minhas dicas sobre como começar a cobrir sua aplicação com testes e a implementar um bom fluxo de trabalho:

  • comece com cenários simples, como apenas a verificação de determinado elemento na tela ao acessar uma rota, isso já garantirá que a tela está sendo corretamente (ou o mais próximo disso) renderizada
  • não tente efetuar todos os tipos de testes de uma vez, vá com calma, não tente abraçar o mundo
  • refatoração sem teste não existe
  • desde o primeiro momento, configure algum serviço de Integração Contínua, mesmo que seja apenas para rodar testes de cada commit
  • quando o CI estiver com um fluxo legal, configure também uma Entrega Contínua

Caso você se interesse em implementar um sistema de integração contínua, no blog existem alguns textos que podem te ajudar no processo, ou fale diretamente comigo que terei prazer em ajudar.

Até a próxima ;)

Integração Contínua com Bitbucket Pipelines

Finalmente, mais um post para a série: Integração Contínua.

A correria anda tornando cada vez mais impossível estudar a quantidade de ferramentas que temos por aí, mas aos poucos o projeto vai caminhando.

No último post, prometi que o artigo a seguir seria sobre PHPCI, mas o Bitbucket liberou para todos os Pipelines - antes estava restrito a apenas alguns desenvolvedores e somente para repositórios que não fizessem parte de um time ou projeto - e foi a ferramenta de CI escolhida para a equipe do qual faço parte na BêeCambio, resolvi falar sobre ela antes.

Bitbucket Pipelines Logo

Parando de enrolação, vamos ao que interessa, Pipelines!

Apresentação

O Pipelines era sem dúvida a ferramenta que faltava para quem trabalha com repositórios no Bitbucket. Simples de configurar, utiliza Docker e grátis, inclusive para repositórios privados.

Instalação

A instalação do Pipelines é bem simples, bastando que você habilite no menu lateral e siga os passos na tela. A instalação inicial, se divide em dois passos bem simples

Passo 1

Clicando no menu lateral, tem um pequeno slideshow apresentando o Pipelines e solicitando que você concorde com a instalação, já que ele vai criar um novo arquivo no seu projeto - não se preocupe com isso agora.

Passo 2

O segundo passo da instalação, é selecionar o ambiente que você pretende configurar, existem várias opções, cada uma irá apresentar um esqueleto bem simples de configuração para cada tipo de projeto, não se preocupe com o que aparecer na tela, futuramente você poderá editar este arquivo.

Configurando

Finalizando os passos, será criado no projeto o arquivo bitbucket-pipelines.yml, contendo a configuração do ambiente e dos passos necessários para alcançar o sucesso do nosso build.

Aqui vem a parte chata da configuração, toda modificação que você fizer neste arquivo, é um commit + push que você precisa mandar pro projeto - você também pode rodar os builds localmente, mas dá trabalho. Pessoalmente, acho um pouco chato isso e suja o projeto, mas vamos lá.

O ambiente de integração, utiliza containers do Docker para rodar, então, o nosso primeiro passo na configuração do projeto, e informar a imagem que precisamos utilizar para nosso build. Esta imagem pode ser tanto um container disponível no Docker Hub quanto um container próprio.

Caso você não especifique uma imagem, será utilizada uma imagem padrão, baseada no Ubuntu 14.04, disponibilizada pelo time da Atlassian, que contém algumas ferramentas por padrão:

  • wget
  • xvfb
  • curl
  • git: 1.9.1
  • java: 1.8u66
  • maven: 3.0.5
  • node: 4.2.1
  • npm: 2.14.7
  • nvm: 0.29.0
  • python: 2.7.6
  • gcc: 4.8.4

A configuração do Pipelines é baseado em blocos de passos, chamado no arquivo de configuração de step.

Cada step possui um script, que são os comandos rodados para a conclusão do build. Cada linha, do script, é um comando rodado após o término do anterior.

O bloco default irá rodar os passos configurados nele para todos os branchs que receberem uma atualização, como um push ou um merge.

Você também pode criar blocos de configurações para determinados branchs ou tags, e rodar os passos achar necessário. Eu gosto muito desse tipo de configuração, para disparar o evento de deploy, que sempre deixo a cargo de outra ferramenta.

Um exemplo do arquivo de configuração é esse:

# This is a sample build configuration for PHP.
# Check our guides at https://confluence.atlassian.com/x/VYk8Lw for more examples.
# Only use spaces to indent your .yml configuration.
# -----
# You can specify a custom docker image from Docker Hub as your build environment.
image: phpunit/phpunit:5.0.3

pipelines:
  default:
    - step:
        script: # Modify the commands below to build your repository.
          - composer install

Você pode ter uma referência completa do arquivo de configurações aqui.

Bônus Track - Exemplos de Configuração

Como sempre, vou mostra abaixo algumas configurações utilizadas nos projetos que tenho no Pipelines, e também algumas disponíveis no próprio guia do Pipelines.

PHP

image: phpunit/phpunit:5.0.3

pipelines:
  default:
    - step:
        script:
          - composer --version
          - phpunit --version
          - composer install
          - phpunit --configuration tests/phpunit.xml

Nodejs

image: node:6.0.0

pipelines:
  default:
    - step:
        script:
          - npm install --silent --progress=false
          - npm test

Meu bloco scripts do package.json:

...
"scripts": {
  "start": "node app.js",
  "test": "mocha test/**/*Test.js",
  "coverage": "istanbul cover _mocha -- -R spec"
},
...

Angularjs

image: node:6.0.0

pipelines:
  default:
    - step:
        script:
          - npm install --silent --progress=false
          - npm run bower
          - npm run build
          - nohup bash -c "npm run webdriver-start 2>&1 &" && sleep 9
          - npm run start 2>&1  &
          - npm test

Meu bloco scripts do package.json:

...
"scripts": {
  "bower": "bower install",
  "build": "gulp build",
  "start": "gulp serve",
  "webdriver-start": "webdriver-manager update && webdriver-manager start",
  "test": "protractor protractor.conf.js"
},
...

Ruby

image: ruby:2.3.0

pipelines:
  default:
    - step:
        script:  # Modify the commands below to build and test your repository.
          - ruby --version
          - bundler --version
          - bundle install

Java

# You can use any Docker image from Docker Hub or your own container registry
image: maven:3.3.3

pipelines:
  default:
    - step:
        script:  # Modify the commands below to build and test your repository.
          - mvn --version
          - mvn clean install

Trabalhando com múltiplos branchs

image: node:6.0.0

pipelines:
  default:
    - step:
        script:
          - npm install
          - npm test

  branches:
    develop:
      - step:
          script:
            - npm install
            - npm test
            - npm run deploy:develop

    homolog:
      - step:
          script:
            - npm install
            - npm test
            - npm run deploy:homolog

    master:
      - step:
          script:
            - npm install
            - npm test
            - npm run deploy:production

Prós & Contras

A favor do Pipelines, tem muita coisa, apesar de ser uma ferramenta nova e ainda em sua versão beta, ela cumpre o que promete e reconhece suas limitações.

Os builds rodam muito rápido e fazer parte do Bitbucket, e não como uma ferramenta a parte, conta muitos pontos.

Rodar sobre o docker também é muito bom, porque permite um controle maior de todo o ambiente, sem a necessidade de ficar dando manutenção em servidores.

Como não podia faltar em nenhuma ferramenta de CI, existem várias integrações prontas para utilizar, como Deploy para S3, Heroku, Azure e etc.

Contra, por enquanto, é que o Pipelines ainda é um pouco problemático com o arquivo de configuração - talvez isso seja problema do próprio yaml - mas as vezes incomoda e fica difícil de debugar sem sujar o repositório com vários commits. Talvez um validador online facilitasse as coisas.

Conclusão

Para quem utiliza exclusivamente o Bitbucket como controle de versão e possui projetos privados, mas não quer gastar uma quantia considerável para rodar utilizar uma ferramenta de CI, o Pipelines cai como uma luva.

Com uma configuração bem simplificada, sem a necessidade de instalar dezenas de ferramentas anteriormente e etc, é a ferramentas ideal para equipes e projetos de qualquer tamanho, possibilitando um fluxo de entrega muito mais ágil e de configuração visível para todos os membros da equipe. Possibilitando inclusive simulações locais do ambiente de build.

Rodando sobre Docker, é possível manter ainda mais controle sobre o ambiente necessário para o ideal funcionamento do projeto, dando ainda mais transparência sobre o processo.

Mais Informações

E é isso, obrigado pela leitura, espero que tenha curtido o post e nos vemos nos próximo da série ;)

Integração Contínua com Jenkins

Voltando a nossa série sobre Integração Contínua, vou apresentar agora a você o Jenkins.

Acho que simplesmente, o mais famoso e utilizado de todos - e também, o mais complicado de se manter.

Jenkins Logo

Pra não quebrar o padrãovulgo TOC, vou dividir o post em algumas partes:

Apresentação

Eu sempre digo que o Jenkins é o xodó da comunidade, porque 9 entre cada 10 projetos que eu tenho contato, que utilizam - ou tentam - utilizar Integração Contínua, utilizam ele em sua stack.

Instalação

O Jenkins pode ser instalado de várias formas, o jeito mais simples, é utilizando o nosso tão conhecido apt-get ou yum, mas também pode ser instalado via homebrew para os usuários de Mac, ou simplesmente rodando o jar baixado no site. Eu prefiro sempre a primeira opção, buscando um repositório constantemente atualizado e etc.

Outra opção rápida que temos, apenas para fins de testes, é a VM disponibilizada pela Openshift, a instalação é automática em poucos cliques, e você recebe o seguinte ambiente configurado por padrão:

  • PHP 5.3.3
  • Java 1.7.0_111
  • Nodejs 0.6.20
  • Ruby 1.8.7

Tudo bem desatualizado eu sei, mas como eu disse, para fins didáticos está ótimo.

Agora, se você preferir uma instalação local, eu recomendo que o faça em uma máquina Linux utilizando um repositório atualizado, ou baixando o war direto do site.

Mas para este artigo, preferi utilizar o Docker e instalar o Jenkins disponibilizado no DockerHub:

docker pull jenkins

E mandei bala para rodar, é importante dar atenção a saída do log na tela, para pegarmos a chave de autenticação inicial, para podermos prosseguir com a instalação:

docker run -p 8080:8080 -p 50000:50000 jenkins

Feito isso, abrimos o endereço http//localhost:8080 e temos o primeiro passo da instalação, onde inserimos a chave gerada quando subimos o serviço:

Desbloqueio

Desbloqueada a tela, você tem duas duas opções para prosseguir, por hora vamos na primeira porque é mais prático:

Plugins Plugins 2

Após tudo instalado - espero que você tenha lembrado de pegar um café enquanto o download dos plugins acontecia -, caímos na tela de criação de usuário, mas você também pode clicar em continuar como admin caso não vá compartilhar o ambiente com mais ninguém.

Usuário Instalado

Tudo instalado e rodando bonitinho, temos o Jenkins funcionando e exibindo a tela inicial vazia, pois ainda não criamos nenhum trabalho.

Dashboard

Configurando

O Jenkins precisa que as ferramentas que você necessita para rodar o seu build (como a versão correta do PHP, Nodejs ou JDK por exemplo) estejam devidamente configuradas e funcionais na máquina hospedeira, então, fique sempre atento a isso.

Antes de criarmos um trabalho, vamos configurar alguns ítens importantes, clicando em Gerenciar Jenkins no menu a direita e após em Configurar o Sistema.

Nesta tela, você pode configurar uma mensagem de boas vindas, o número de executores, que define quantos builds você pode fazer em paralelo. Lembre que cada executor é uma thread, então não exagere. O padrão é dois.

Config

Outro ítem importante - mas não obrigatório -, são as variáveis de ambiente. Eu gosto muito de utilizar este recurso, para definir qual ambiente, acessos a serviços e etc.

Variáveis de ambiente

Se você deseja que o resultados dos builds sejam enviados por email, é importante configurar também, um servidor SMTP para o envio das mensagens:

SMTP

Uma outra sessão muito importante é a de plugins, lá você encontrará muita coisa interessante para deixar o seu Jenkins ainda mais turbinado, é extensa a lista e compensa separar alguns minutos - ou horas - para testar alguns plugins. Alguns que recomendo:

A lista é curta, mas isso é diversão e vou deixar por sua conta, apenas tenha em mente que, encher o ambiente de plugins, não é lá uma ótima idéia ;)

Agora precisamos configurar como o Jenkins irá se comunicar com nossos servidores e sistemas de controle de versão. Eu recomendo a criação de uma chave SSH própria para o usuário do Jenkins no servidor onde ele esta rodando, no nosso caso, nosso container. Vamos primeiro acessar o container, e criar a chave manualmente:

[email protected]:~$ ssh-keygen
Generating public/private rsa key pair.
Enter file in which to save the key (/var/jenkins_home/.ssh/id_rsa):
Created directory '/var/jenkins_home/.ssh'.
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /var/jenkins_home/.ssh/id_rsa.
Your public key has been saved in /var/jenkins_home/.ssh/id_rsa.pub.
The key fingerprint is:
1f:88:67:90:dd:84:5e:8c:fa:3c:69:b7:c9:e8:02:a1 [email protected]
The key's randomart image is:
+---[RSA 2048]----+
|         +.      |
|       oooo      |
|      oo...      |
|    . .o..       |
|   . ..oS..      |
|  E .  o*...     |
|     . . =.o     |
|      . . +      |
|       o.        |
+-----------------+

Agora, voltando para nossa interface do Jenkins, clicando no menu a direita, vamos em Credentials, System, Global credentials e finalmente em Add Credentials. Onde iremos nos deparar com a tela a seguir, que nos permitirá configurar vários meios de autenticação, por hora, ficaremos apenas definindo que o Jenkins utilizará a chave do usuário padrão do container.

Credenciais

Criando o primeiro trabalho

Agora que temos nosso Jenkins configurado, podemos nos aventurar a conhecer a tela de criação de trabalhos do Jenkins, é nela é claro, que vamos configurar todos os passos do nosso build. Aqui, é importante configurar todos os passos necessários, para garantir que todo o fluxo de construção de nossa versão estável rode perfeitamente. A dica é, se você hoje faz todo o processo manual, anote os passos para não esquecer de nenhum, e aí sim, configure os mesmos no Jenkins.

Os passos de build vai de cada aplicação, mas não foge muito do processo:

clonar -> dependências -> testes -> build -> publicação

Nosso primeiro passo é ao clicar em “Novo job”, selecionar o tipo de projeto que vamos configurar, para um primeiro passo, prefiro utilizar o “free-style”, que é uma configuração limpa e podemos prosseguir configurando os passos conforme a necessidade de nosso projeto.

Tipos

Com o tipo de projeto configurado, vamos nos deparar com a tela de configuração do trabalho em si, onde iremos configurar todos os detalhes do projeto.

Na primeira parte, vemos como configurar além do nome do projeto - procure não mudar aqui, nem utilizar caracteres estranhos, a cópia de trabalho é baseada neste nome - um espaço para preenchermos uma descrição do mesmo. Você pode utilizar este espaço para exibir uma imagem com a sua cobertura de código por exemplo ;)

Detalhes

Em seguida, temos a opção de Descartar builds antigos, importante para salvarmos nosso espaço em disco, já que cada build, pode ocupar um espaço considerável em disco, contabilize quanto isso não daria por semana ou mês.

Eu procuro não manter um número muito grande de builds armazenados, já que os mesmos rodam a cada push - e vai por mim, você também não vai querer que seu disco encha rapidamente - mas é importante ter um número suficiente que te permita voltar a um estado anterior a publicação atual.

Histórico

Em seguida, selecionando o nosso controle de versão definimos o endereço do nosso repositório, assim como o branch a ser observado.

Código Fonte

É também nesta tela que podemos definir qual o tipo de autenticação iremos utilizar para autenticar o Jenkins em nosso repositório, clicando em Credentials podemos selecionar a chave criada no início, na tela de configurações, ou mesmo adicionar uma nova. Lembre-se de adicionar o conteúdo da chave pública do Jenkins, como uma chave válida para deploy em seu controle de versão.

Com o acesso ao repositório configurado, podemos definir quando nosso build ocorrerá automaticamente, você possui várias opções, eu gosto muito de habilitar tanto checagem automática a cada hora, quanto a cada push que o repositório receber. A checagem periódica usa o mesmo padrão da cron, então, é possível também utilizar valores como @hourly, @daily e etc, dependendo do tamanho do seu projeto e de quanto tempo leve o build, seja uma boa idéia chegar num valor que não atrapalhe a equipe aqui, criando filas de builds desnecessários.

Periodicidade

O próximo bloco é sobre o ambiente, onde você pode limpar sua área de trabalho, habilitar alguns plugins e etc. Gosto de habilitar um plugin chamado ci-skip, para atualizações que não requerem um build, como uma atualização do arquivo README do projeto por exemplo.

Ambiente

Os próximos blocos são bem semelhantes, porém, no primeiro, você configura todos os passos necessários até que seu projeto seja definido como entregável, o segundo, são os passos a ser executados após o build ser definido como tal. Lembre-se, que cada passo de build depende do sucesso do seu anterior, então, é uma boa prática não juntar todos os passos num bloco só de build.

Builds

Nos próximos passos, vou mostrar como fazer uma configuração básica para projetos em algumas linguagens comuns no mercado.

Bônus Track - Exemplos de Configuração

PHP

No exemplo em PHP, a configuração é bem simples, bastando rodar o composer - previamente instalado - para instalar as dependências do projeto, e em seguida, o testes com o PHPUnit, o que me garante o sucesso do build.

PHP

Nodejs

Nodejs

Ruby

Ruby

Java

Para nosso exemplo em java, utilizei a criação do trabalho do tipo Maven. Java

Em seguida, adicionei o repositório e deixei nas configurações default, para que ele leia o arquivo POM do projeto e tente executar o build. Java

Prós & Contras

O Jenkins é uma aplicação robusta e tem plugin para realmente tudo. Por ser uma ferramenta que está a muito tempo no mercado, é bem madura e faz o que promete.

Em alguns momentos, cuidar de uma instância Jenkins é bem chato, principalmente por culpa do Java, já passei por momentos em que tive que trocar do JDK da Oracle, para o OpenJDK e vice-versa, por culpa de altos consumos de CPU.

Conclusão

Não tem como não recomendar o Jenkins para quem deseja implementar uma integração contínua em sua stack. Eu já o utilizei muito pelas empresas que passei e também na minha vida de freelancer. Gosto muito de distribuir minha stack em serviços, então, minha preferência é sempre por utilizar PaaS, porém no caso do Jenkins, nem sempre isso é possível, já que os serviços podem sair bem caros dependendo do tamanho do seus projetos e da quantidade de builds que você pretende rodar.

Caso queira testar e sua máquina, deixei em meu GitHub, um container pronto para uso, que é mesmo que utilizei para escrever este artigo.

Mais Informações

Por hoje é isso, o próximo artigo é sobre o PHPCI, aguarde e até lá.

Integração Contínua com CodeShip

Codeship Logo Continuando a série sobre Integração Contínua, partimos agora para o CodeShip, que assim como o Travis-CI, também é uma ótima ferramenta online para implantar Integração Contínua em seus projetos.

Mas ao contrário do Travis-CI, o CodeShip nos permite adicionar repositórios privados sem custo algum - mas o limite é de 5 repositórios - assim como ilimitados repositórios de projetos de código fonte aberto.

Assim como no último post, vamos dividir este também em algumas partes, para facilitar a leitura e o entendimento da ferramenta.

Apresentação

Conheço a relativamente pouco tempo o CodeShip, mas sua facilidade de uso e simplicidade me convenceram logo de cara a utilizá-lo no projeto de um cliente, e logo tomei-o também para alguns projetos pessoais, como alternativa ao Travis-CI.

Claro que a primeira coisa que me chamou a atenção, foi a possibilidade de utilizá-lo gratuitamente para projetos privados, mesmo com um número limitado de builds mensais para estes - no momento em que escrevo este artigo, o limite é de 100 builds.

Uma funcionalidade muito interessante é a possibilidade de rodar testes em paralelo, para agilizar o processo de build, porém, esta somente está disponível para contas pagas - mas você pode testar por duas semanas sem compromisso ;)

Codeship - Paralell Build

Cadastro

O cadastro é simples, com poucos campos - bastando você informar seu nome, email, senha e pronto - ou conectar-se diretamente com sua conta do Bitbucket ou GitHub. No caso dos dois sites, você também pode conectá-los depois do cadastro, facilmente.

Eu preferi conectar diretamente com minha conta do Bitbucket e fiz a integração com o GitHub posteriormente, sem problema algum.

Após efetuar o cadastro, você cai direto na DashBoard, onde ficam listados os últimos builds - claro que no caso de novos cadastros, somente é apresentada uma tela de boas vindas e adição de projeto.

Na imagem abaixo, mostro a tela inicial, com builds com sucesso e outros com falhas para você ver: Codeship - DashBoard Nenhum projeto foi sacrificado ou sofreu crueldades para produzir esta imagem.

Configurando

A configuração do CodeShip é toda por sua interface, que aliás, é muito simples e resumida, sem muitas surpresas. O primeiro passo, é selecionar o ambiente a ser utilizado, basicamente, você seleciona a plataforma e ele te da algum exemplo de código, como abaixo. Codeship - Configurando 1

Após a escolha, é possível editar e dar uma melhorada no ambiente. Nas contas pagas, é possível definir diversos “pipelines”, ou seja, rodar diversas métricas em paralelo, para melhorar a performance. Testei em um projeto e não tive um ganho muito significativo pra compensar o uso pra falar a verdade, mas creio que isso seja um problema na minha arquitetura. Codeship - Configurando 2 É possível utilizar algumas variáveis de ambiente pré-definidas

Existem ainda as diversas integrações para configurar o deploy automatizado, como AWS, Digital Ocean e etc., assim como também é possível você rodar seu próprio script, ou mesmo o Curl para enviar uma chamada a outro serviço, como é o meu caso com o DeployBot - esse eu prentendo falar em um outro artigo futuro. Codeship - Configurando 3

Finalizando a configuração do Deploy, você também pode configurar notificações:

Codeship - Configurando 3
Codeship - Configurando 3

Assim como o Travis-CI e outros serviços, também é possível configurar as próprias variáveis de ambiente, para serem utilizadas durante o processo: Codeship - Configurando 3

E se tudo der certo - ou mesmo se der tudo errado -, você pode conferir os detalhes do build: Codeship - Configurando 3

Bônus Track - Exemplos de Configuração

Como não poderia deixar de faltar, vou mostrar alguns exemplos de configuração para algumas linguagens comumente usadas

PHP

## Tests Config
# Set php version through phpenv. 5.3, 5.4, 5.5 & 5.6 available
phpenv local 7.0

# Install extensions through Pecl

# yes yes | pecl install memcache

# Install dependencies through Composer
composer install --prefer-source --quiet --dev --optimize-autoloader --no-interaction
### Pipeline
./vendor/phpunit

Nodejs

# Tests
nvm install 0.10
npm install
# Pipeline
npm run test-single-run

Angularjs

# Tests
nvm install 0.10
npm install
# Pipeline
npm run protractor

Ruby

# Tests
rvm use 2.2.0 --install
bundle install
# Pipeline
bundle exec jekyll build
bundle exec htmlproof --allow-hash-href --disable-external --empty-alt-ignore ./_site

Java

# Tests
ant deps
# Pipeline
ant test

Prós & Contras

O CodeShip é simples e prático de configurar por isso mesmo tornou-se rapidamente uma das minhas ferramentas de uso constante nos projetos. Seu processo de build é relativamente rápido e com suas diversas integrações, você pode, de forma simples e direta, configurar um deploy automatizado ao final dos testes. O suporte a processos paralelos é um grande atrativo, porém, em meus testes não obtive um resultado que compensasse a troca de plano.

O valor não é um grande atrativo para nós reles mortais brasileiros, o plano mais barato fica em torno de $49 no momento em que escrevo esse artigo, com suporte a dois “Pipelines” e um número ilimitado de projetos, tanto privados quanto públicos.

Também existe um plano intermediário, recente, com suporte a Docker, que parece ser muito interessante, porém, não tive a chance de testar ainda, então, não tenho muito o que dizer.

O suporte a times também é um diferencial, possibilitar que você crie um ambiente compartilhado com a equipe para que todos possam acompanhar de perto todo o processo é excelente ao meu ver, e se você puder fazê-lo, faça!

Conclusão

Logo a primeira vista, o CodeShip demonstra ser uma excelente ferramenta, e no decorrer do uso, ela prova isso. Sua documentação é simples e vai direto ao ponto, durante meus testes, foi realmente tranquilo obter as informações necessárias para definir o ambiente de testes e o processo de publicação.

Como não poderia deixar, ele também possibilita o uso dos Badges - todo programador gosta de colocar um frufru no README, admita. Codeship - Badge

Então é isso, o CodeShip é mais que recomendado para você que quer iniciar um processo de Integração ou Entrega contínua em seus projetos, mas não quer perder tempo com arquivos de configuração, configuração de servidores ou longos processos.

Sua configuração simplificada e integração direta com o BitBucket e GitHub facilitam e muito o uso por grande parte das equipes e facilita sua implantação. Poder utilizar a ferramenta gratuitamente para projetos OpenSource também é um grande diferencial, claro.

Mais Informações

O próximo da lista é Jenkins, prepare-se e até lá ;)