Integração Contínua

Integração Contínua

O que é?

A Integração Contínua (CI – Continuous Integration) é um processo que exige que os programadores integrem, num repositório partilhado por toda a equipa, o código desenvolvido por si, pelo menos uma vez por dia. Num Universo utópico, as integrações deverão ocorrer várias vezes ao dia, essencialmente a cada ‘push’ de código para o repositório. Esta acção dispoletará uma ‘build’ automatizada.

Porquê?

As metodologias Agile exigem o código esteja sempre “preparado” para uma eventual entrega. Este processo de integração contínua do código de toda a equipa, na base de código em que se está a trabalhar, permite se detectar problemas bastante mais cedo.

Num processo Waterfall, cada entrega de código poderia demorar vários meses a acontecer. Como podes imaginar, nessa altura era recorrente que num dia de entrega se convocasse uma “sala de guerra”, onde deveria estar toda a equipa de desenvolvimento, a equipa de operações, a equipa de produto, a equipa de qualidade, a equipa de gestão. O processo de entrega era um verdadeiro caos, e poderia levar várias horas a decorrer (não contando com possíveis problemas que pudessem ocorrer, e que deveriam ser atacados de imediato pela equipa responsável).

De facto, nessa altura imaginar que a cada ‘push’ para o repositório poderia correr uma bateria de testes (unitários, integração, aceitação, …) e obter feedback se eventualmente as minhas alterações iriam partir alguma funcionalidade existente, era impensável. Uma verdadeira aventura !!

Como?

Existem imensas opções para quem quer começar a construir uma pipeline de desenvolvimento com integração contínua. O mais conhecido do momento talvez seja o Jenkins. Uma ferramenta open-source de CI escrita em JAVA. Para quem não quer adicionar mais uma ferramenta à, quase infindável, lista de ferramentas que se tem de gerir e administrar, existem várias opções SaaS. De momento, na log, utilizamos o SaaS Codeship da CloudBees.

Uma vez configurada a pipeline de integração contínua, sempre que ocorrer um “push” para um repositório Git, irá correr um processo automático onde será levantado um ambiente virtual com as características por nós definidas, dentro do qual irá ocorrer a “build” do projecto e posteriormente correrão os testes – unitários, integração, aceitação, mutação, …

Em qualquer um destes pontos, caso ocorra um qualquer problema, o processo de integração contínua falhará e teremos o relatório do problema. Importante referir que se o processo de integração falhar, não haverá qualquer possibilidade de se efectuar um deploy – automático ou manual – para qualquer que seja o ambiente.

Não é possível utilizar “eXtreme Programming” sem este processo !!

WordCamp Londres 2018

WordCamp é uma conferência que foca em tudo o que seja WordPress. WordCamps são eventos informais, organizados pelas comunidades de utilizadores de WordPress como tu. Qualquer um, desde utilizador casual a developers do core, participam, partilham ideias e conhecem-se uns aos outros.

Como se pode ver pela descrição presente no site da “central” de WordCamps realizados pelo Mundo fora, os WordCamps são momentos de partilha de conhecimentos e experiências, mas também uma oportunidade de expandir redes de contactos e formar parcerias.

log, empresa para a qual trabalho, irá patrocinar o WordCamp Londres e estará presente para apresentar os seus serviços de desenvolvimento em “Nearshore”. É com bastante entusiasmo que farei parte da comitiva. Será um prazer poder passar dois dias a falar com outros programadores de WordPress e, com bastante orgulho, promover a qualidade de código desenvolvido pela minha equipa.

Continuo a acreditar que é possível promover e disseminar a utilização das boas práticas de engenharia que o eXtreme Programming aconselha. Certamente que este será mais uma oportunidade para debater o tema.

Encontramo-nos em Londres?

Programação Pareada

Programação Pareada

O processo de programação pareada (em pares) é uma metodologia de trabalho defendida pelo eXtreme Programming (XP). Como o nome refere, cada unidade de programação é constituída por dois programadores num único computador. Poderemos incorrer no erro de pensar que é um desperdício de capacidade humana, uma vez que estão dois elementos a realizar o trabalho de um. No entanto esse pensamento não poderia estar mais afastado da realidade.

É expectável que uma equipa pareada produza a mesma quantidade de código que seria de esperar de dois programadores individuais, no entanto com a mais valia do código ter maior qualidade. Num artigo anterior escrevi sobre a importância e o papel da revisão de código no desenvolvimento de software. Processo que também consome tempo no presente mas que nos permite ganhar tempo no futuro através da maior maturidade e qualidade do código que seguirá para produção. Se se optar pela metodologia da programação em pares, poder-se-á presumir que a revisão de código já estará presente no código desenvolvido pela dupla de programadores.

Cada um dos programadores terá um papel específico – o “condutor” e o “navegador”.

Isto é, um escreve código enquanto o outro lê e antecipa situações. O melhor entrosamento verifica-se quando o teclado passa de um para o outro, sem que nenhum dos elementos esteja agarrado ao seu papel pre-estabelecido. Como se poder constatar, programação em pares tem tanto de soft-skills como de technical skills. Não é fácil para um programador aceitar a opinião de um par antes de testar a sua opinião. Como todas as demais soft-skills, é possível desenvolvê-la mas que requer tempo e abertura da parte do indivíduo.

“Já que vou ter de colocar dois programadores juntos, o melhor é colocar um sénior junto com um júnior, assim ele vai poder aprender”.

É preciso muito cuidado com este pensamento. A relação de mentoria é diferente da relação entre pares. Se efectivamente se pretende que a produtividade não diminua, a equipa deverá ser constituída por programadores competentes e já numa fase em que são totalmente autónomos.

Existem empresas que optam até por definir os papeis como “programador” e “tester”, ou seja, o “programador” irá escrever código para os testes unitários desenvolvidos pelo “tester”. Estes papéis vão sendo trocados e chegam mesmo a trocar no próprio dia. Como se pode compreender, seria completamente impossível de o fazer se os dois elementos não estivessem no mesmo nível de autonomia e conhecimento.

Outra indicação que o eXtreme Programming nos dá, “mover as pessoas”. É importante que as equipas pareadas sejam trocadas regularmente. Com isso iremos prevenir o aparecimento de “ilhas de conhecimento”, que de futuro nos poderá encaminhar para uma dívida técnica caso os detentores do conhecimento decidam sair da empresa – fenómeno tão temido por qualquer gestor tecnológico.

Assim se percebe que aliando a programação pareada a uma rotação interna de programadores obtemos maior:

  • fluxo contínuo de desenvolvimento e entrega,
  • disseminação de conhecimento da base de código do projecto,
  • qualidade no código produzido,
  • diminuição de possíveis dívidas técnicas.

 

Padrões de Código

És dos programadores que pensa que ter o código codificado numa espécie de cifra, a qual só tu entendes, para que ninguém te possa roubar o teu código, ou para que mais dificilmente te possam substituir numa equipa?

Espero que leias o artigo até ao fim pois tenho para ti algumas más notícias.

Aos restantes, leiam também que irão encontrar valor certamente.

A comunidade WordPress tem como slogan “code is poetry (código é poesia)“. Eu prefiro idealizar o código como uma boa prosa, escrita com atenção, com boas regras de pontuação e sem segundos sentidos. Basicamente, respeitando as máximas do “clean code (código limpo)“.

Padrão (substantivo masculino), o que serve de modelo ou referência.

Segundo a definição, tudo o que possa servir de modelo ou referência que permita consistência pode ser considerado um padrão. Assim, um padrão de código poderá ser somente um guia de estilo (coding style); como poderão ser fórmulas de resolver determinados problemas, designados por padrões de desenho (design patterns).

A utilização deste tipo de regras permite uma maior legibilidade do código. Ou seja, mais facilmente o código poderá ser lido e entendido por outras pessoas. Ao contrário da premissa do início do artigo, a existência de mais “olhos” sobre o código aumentará substancialmente a detecção de possíveis falhas de performance ou segurança. Com isto também se irá diminuir o sentimento de único proprietário do código, permitindo uma mais fácil partilha de conhecimento entre toda a equipa. Não, não te vão roubar o lugar…na realidade, terás mais oportunidades de evoluir enquanto programador, e isso sim, te fará manter na profissão que escolheste durante mais tempo.

(Fonte: Rose-Hulman – Institute of Technology)

Os padrões de desenho já existem há considerável tempo, existindo uma “bíblia” escrita pelo gangue dos 4 – Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides – “Design Patterns: Elements of Reusable Object-Oriented Software“.

No entanto, com este artigo pretendo me focar mais sobre os guias de estilo.

Diariamente, na log, utilizamos PHP e WordPress, JavaScript, CSS e HTML. Penso que todas as linguagens de programação terão algum tipo de guia de estilo.

Para PHP existe um projecto designado por “PHP Framework Interop Group” onde se debatem e decidem quais os padrões que deverão vigorar. As recomendações para guias de estilo são o PSR-1 (Basic Coding Standard) e o PSR-2 (Coding Style Guide). Existe uma proposta, ainda em estado de rascunho, para um guia de estilo alargado (PSR-12).

O WordPress, apesar do seu código-base ser PHP, sugere um guia de estilo diferente – WordPress Coding Standards – que contradiz alguns pontos do PSR-2. Se pretendes desenvolver plugins, temas ou participar na evolução do core do WordPress, então terás de respeitar o seu guia de estilo.

Na nossa equipa respeitamos o guia de estilo do WordPress, e adicionamos mais algumas regras. Podes ler, usar e contribuir no nosso github.

Muitas vezes, se não a maioria das vezes, este tipo de iniciativas nasce dentro de empresas que não estão directamente associadas à evolução da linguagem ou framework (ou CMS). Um bom exemplo disso é o guia de estilos para JavaScript escrito pela empresa airbnb. Uma das vantagens do código-livre, o projecto poder nascer dentro de uma empresa e passar a ser do Mundo quando existem mais pessoas externas a participar na manutenção e evolução do mesmo.

Para CSS existem várias metodologias como o BEM (Block Element Modifier) que nós utilizamos na log.

No fundo não interessa se vais adoptar o guia de estilo A ou B, mas sim se algum será adoptado dentro da tua equipa. Esse é o desafio maior e onde se sentirão os maiores benefícios. O sentimento de propriedade partilhado por toda a tua equipa fará aumentar a qualidade do código por vocês escrito. Melhor qualidade de código, menor o número de bugs reportados. Melhor código facilitará a sua manutenção. Melhor código permitirá um sistema mais estável e mais maduro. Terás orgulho em ter escrito parte de um bom sistema, assim como o teu empregador.

Como vês, os beneficios serão de toda a equipa, e de ti também.

easing a hurricane called TEAM

Meetup WordPress Porto

Tive o prazer de participar no Meetup mensal da comunidade WordPress do Porto. Um grupo que se reune mensalmente, ininterruptamente há 4 anos. Viajar até à cidade do Porto é sempre um prazer, apesar dos mais de 300km de distância de Lisboa.

easing a hurricane called TEAM

(acalmando um furacão chamado de EQUIPA)

O titulo da apresentação que levei ao Porto. A apresentação começa com uma breve viagem por alguns momentos da minha carreira de programador de software. Com passagem obrigatória por alguns “dramas” mas que, sem esses obstáculos, não seria efetivamente o que sou hoje. Esses momentos também me permitiram conhecer dos melhores profissionais da área. Alguns dos quais tenho o prazer de, ainda hoje, privar com e de poder apelidar de amigos.

Com eles aprendi o que era SCRUM e eXtreme Programming, e qual a importância do papel humano de um CTO.

Anos volvidos, eis que me encontro no papel de coordenar uma equipa numa empresa que promove a implementação de algumas boas práticas do eXtreme Programming.

A segunda parte da apresentação versa sobre como as boas práticas (coding standards, code review, test-driven development, continuous integration, continuous delivery) fazem maravilhas na e para a minha equipa diariamente.

No próximo dia 2 Novembro terei a oportunidade de revisitar esta apresentação mas agora em Lisboa no change.log.

Espero vos encontrar por lá.