Algumas boas práticas sobre APIs

Existe ainda alguma confusão sobre APIs. Muitos gestores acreditam que uma API é um algum termo nerd discutido nos porões do desenvolvimento de software. E muitos desenvolvedores acreditam que uma API é apenas um conjunto de funções expostas a partir da sua IDE para habilitar a integração da sua aplicação com algum front-end.

Outros gestores e desenvolvedores mais atentos já observaram que APIS são ferramentas que podem aumentar suas receitas e reduzir o TCO de seus códigos legados. Um exemplo muito bacana no contexto brasileiro é como market places tem aumento o faturamento de grandes redes varejistas. E já existem também congressos temáticos no Brasil para discutir as possibilidades de negócio como por exemlo o API Experience.

APIs, definitivamente, vieram para ficar. APIs podem potencializar aplicações legadas, abrir novos canais de parcerias de negócio e até mesmo criar novos produtos para as suas áreas de negócio.  E isso é muito bom para que TIs possam prover mais alinhamento e valor de negócio.

Mas como podemos nos locomover no mundo das APIs? Como iniciar e gerar valor com elas?

Se você perguntar para algum fornecedor de ferramenta que precisa alimentar seus filhos a resposta vai ser – Compre a minha ferramenta mágica de API Management. “Ela irá centralizar, segurar, governar e resolver todos os problemas de API da sua organização.” Infelizmente, isso não é verdade e nos leva à primeira diretriz

1. Não compre uma ferramenta de API Management (até que você tenha estabelecido uma cultura mínima de APIs na sua empresa)

Tenho observados casos de fracasso de empresas que tem adotado ferramentas de APIs sem estabelecer API Teams e formar desenvolvedores que entendam minimamente do protocolo HTTP e do estilo REST.

2. Comece pelos fundamentos básicos e apenas depois avance para as tecnologias

Você é o desenvolvedor ultra mega blaster especialista em ASP.NET Web API e SpringBoot, certo?  Mas você ainda acredita que o POST é para incluir um recurso, PUT é para alterar um recurso. E você também nao sabe o significado da palavra idempotência e o seu efeito prático. E você ainda acredita que REST implica em HTTP. Se sim, pare por um momento e fundamente seus conhecimentos.

Conheço muitos “especialistas” em APIs que nunca leram a RFC do protocolo HTTP – https://tools.ietf.org/html/rfc2616 ou as seções centrais do trabalho de origem de Roy Fiedling sobre REST. É como você conhecer um padre que nunca leu uma bíblia ou um cirurgião que nunca leu um livro de anatomia. Os resultados podem ser muito ruins.

Conhecer os fundamentos do protocolo HTTP, REST e princípios arquiteturais para produzir aplicações escaláveis é vital para usar bem os ótimos produtos de API de mercado.

3. Trate APIs como produtos de negócio

No mais recente relatório da APIgee (State of API Report 2017), empresa especialista em APIs comprada pelo Google, foi observado que as empresas mais bem sucedidas no uso de APIs tem tratado APIs como produtos de negócio.

Tratar APIs como produtos aproxima a TI das áreas de negócio, cria valor e potencializa a criação de novos negócios com empresas parceiras.

4. Use tecnologias simples

Não complique o uso de APIs com tecnologias pesadas. Devemos aprender algo com o fracasso dos ESBs e servidores de orquestração BPMS/SOA na primeira década do século XXI.

Fuja dos protocolos  SOAP e WS-*, exceto se você precisa interoperar com governo. E mesmo assim, crie fachadas REST sobre HTTP para não expor complexidades para os seus clientes.

Use produtos leves e de fácil aprendizado, como o ASP.NET Web API, Spring Boot ou Node.JS. Realiza provas de conceitos e crie experimentos. Estabeleça aprendizados e compartilhe experiências na sua empresa.

4.  Crie APIs Robustas

APIs não devem expor funções de negócio (e não tabelas de banco de dados). Muitos times tem criado APIs que operam como CRUDs das tabelas de seus banco de dados. E esta anti-prática já foi documentada aqui como algo ruim pela ThoughtWorks (Anemic REST). Se você encontrar uma API anêmica na sua máquina, copie a mesma para o diretório /dev/null.

APIs devem ter automação de testes. Em 2017, isso nem deveria ser mais lembrado. Ainda assim, é assombroso que existam desenvolvedores por aí que ainda não acreditam em testes de unidade. Mas é assombroso que também existam políticos corruptos no Brasil!

Mas de volta aos testes de unidade, ferramentas como o Swagger, PostMan ou frameworks XUnit são aliados poderosos neste sentido e podem ajudar a manter as suas APIs integras.

APIs devem ter documentação, preferencialmente em um formato navegável e que permita o consumo da API em modelo self-service pelos desenvolvedores de clientes das APIs. Novamente ferramentas bacanas existem aqui com o Swagger, Apiary ou o Slate API Docs Generator.

APIs devem ser baseadas pelo menos no nível 2 de Maturidade RESTful de Richardson

Mas quem é Richardson? E o que ele tem a ver com o meu trabalho?
Leia aqui porque isso é importante para você.

APIs devem ser consistentes entre desenvolvedores e times. Crie com o seu time um padrão apropriado para criar APIs.

Você pode usar algumas boas práticas de mercado e adaptá-las para a sua realidade. Por exemplo, recomendo estes pontos de partida para você o seu time:

5. Governe as suas APIs (Sim! Agora você pode adotar uma ferramenta de API Management)

Você já um API Team, já sabe usar o protocolo HTTP e já começou a estabelecer uma cultura de APIs. Muito bom! Agora você pode baixar uma ferramenta aberta ou comprar uma ferramenta de API Management.

Opções não faltam para você e recomendo o excelente relatório do Forrester de integração híbrida. Use-o como ponta de partida para você selecionar os seus candidatos, fazer provas de conceitos e dar o próximo passo em termos de maturidade na sua organização.

Bons estudos e boas APIs!

API Nerd do Dia – https://developer.marvel.com
(Para aprender como fazer uma boa API com os seus quadrinhos e filmes preferidos).

 

O relatório do estado DevOps – versão 2017

Saiu o tão esperado relatório The State of DevOps Report 2017, da empresa Puppet Enterprises. Este relatório, que compilou mais de 27000 respostas ao longo dos últimos 6 anos, é um trabalho extenso e apresenta os principais benefícios da adoção de práticas DevOps para a sua empresa.

 

Alguns achados interessados do relatório incluem.

 

1. A importância da liderança transformacional nas organizações que querem realizar DevOps. A liderança incluem visão, estimulação intelectural, comunicação inspiracional, suporte e reconhecimento pessoal.
Captura de Tela 2017-06-08 às 18.07.42
 2. As práticas de liderança transformacional estão positivamente correlacionadas com a implantação de práticas DevOps. E estas práticas de liderança e de DevOps estão associadas a produtos melhores, menos problemas em produção e maior performance da sua TI.
Captura de Tela 2017-06-08 às 17.53.54
3. Empresas de alta performance apresentam uma diferença gigante das empresas de baixa performance, conforme pode ser observado no quadro abaixo.
Captura de Tela 2017-06-08 às 17.53.59
Isto é, empresas que praticam DevOps entregam software em produção com muito mais frequência, possuem tempo de ciclo de mudanças muito menor, se recuperam mais rapidamente de incidentes e ainda possuem menor taxa de defeitos em produção.
4. Que práticas DevOps reduzam o volume de trabalho manual em muitas disciplinas técnicas. A tabela abaixo mostra o % de trabalho manual por disciplina para os diversos tipos de empresas.
Captura de Tela 2017-06-08 às 17.54.11
5. Atacar o mito que para fazer DevOps você precisa estar trabalhando com novas tecnologias e usar ambiente de nuvens. Os autores evidenciam que o DevOps pode funcionar em qualquer tipo de ambiente.
“It doesn’t matter if your apps are greenfield, brownfield or legacy — as long as they are architected with testability and deployability in mind, high performance is achievable. We were surprised to find that the type of system — whether it was a system of engagement or a system of record, packaged or custom, legacy or greenfield — is not significant. Continuous delivery can be applied to any system, provided it is architected correctly.”

6. Mostrar a importância de entregar produtos em pequenas partes, colher feedback continuamente dos clientes e melhorar. Qualquer semelhança com MVP não é mera coincidência. O relatório evidencia a importância da entrega contínua para a melhoria do desempenho das TIs. A respeito, recomendo a leitura do livro abaixo. Um clássico já!
41db4qikfil-_sx348_bo1204203200_

7. Apontar a importância do desenho de arquiteturas fracamente acopladas para melhoria de práticas DevOps e a performance da sua TI.

E que venham os microsserviços.

 Observei ainda que houve neste ano um maior rigor estatístico, com o uso de métodos como análise de clusters para classificação de organizações, modelos de equações estruturais para estabelecer correlações e causas e outros modelos estatísticos de regressão (Linear e PLS). Econometria na TI. Isso é muito bom! Em termos simples, isso dá sustentação para você apresentar os números para os céticos na sua organização que ainda não acreditam em DevOps.
O relatório está disponível aqui.  State of DevOps Report, 2017

Agile Trends 2017 – O Veredito

Terminada mais uma edição do  Agile Trends SP, compilo aqui algumas coisas positivas e as tendências que observei.

1. O termo Agile Coach está se solidificando na comunidade ágil para representar o papel que reúne o evangelista, professor, mentor e agente de mudanças que ajuda organizações na jornada da transformação ágil.

2. Estamos vendo cada vez mais empresas que estão adotando modelos de gestão horizontal. Em particular, o caso da empresa Vagas.Com, que possui 150 pessoas e  nenhum nível hierárquico me chamou a atenção. Lá não existem chefes e todas as decisões são baseadas em consenso a partir de um sistema disciplina de abertura e resolução de controvérsias. Vi também outros casos com modelos baseado em holocracias e também até empresa que divulgam abertamente seus salários. Estes exemplos, embora ainda minoritários, são evidências que é possível que empresas possam operar com menos comando e controle e mais auto-organização.

3. O DevOps está se popularizando. Vi vários casos reais de práticas de integração contínua, entrega contínua, automação de testes, provisionamento de ambientes e infraestrutura como código. E o mais notável é como estas empresas estão ganhando tempo, reduzindo custos e erros com o uso destas práticas . E ainda me pergunto por que alguns gestores nas alterosas ainda estão alheios ao poder destas práticas?

4. A combinação Agile + UX está a todo vapor. Personas, Mapeamento de Histórias do Usuário, Design Sprint, Design Thinking e Digital Nudge são alguns das práticas que estão revolucionando a forma como POs capturam e entregam valor em sistemas de informação.

5. Casos, casos e mais casos . A conferência apresentou muitos casos, em empresas dos mais diversos portes, segmentos e orientações. Embora muitos tenham reconhecido a dificuldade da transformação cultural para o modelo ágil, muitos também reconheceram que este esforço gera recompensas técnicas e financeiras.

Se você não pode participar do evento, fique ligado no sítio http://agiletrendsbr.com. As apresentações de 2017 devem ser disponibilizadas em breve, junto com as apresentações dos anos anteriores.

Maturidade DevOps – Pessoas e Robôs colaborando juntos com o ChatOps

Já discutimos nesta série três dimensões da maturidade DevOps.

Iremos agora discutir um aspecto primordial na cultura DevOps, que é o aumento da comunicação e colaboração. Curiosamente, são agora os robôs (ou bots) que vem ao nosso alcance aqui para ajudar times a manter o compasso da comunicação.

Conheça o ChatOps

O ChatOps é a prática do desenvolvimento e operação orientado por conversações. Ao trazer suas ferramentas para suas conversas e usar um bot de bate-papo modificado para trabalhar com plug-ins e scripts, as equipes de desenvolvimento podem automatizar tarefas e colaborar, trabalhando melhor, mais barato e mais rápido.

Ou seja, enquanto estiver em uma sala de bate-papo, os membros da equipe podem digitar comandos que o bot do chat está configurado para executar scripts personalizados e plugins, tais como o disparo de build ou a promoção de código para um ambiente de homologação. Isto é, toda a equipe colabora em tempo real à medida que os comandos são executados.

A figura abaixo exemplifica a arquitetura básica de uma infraestrutura ChatOps.

chatops-fundamental-architecture

Da mesma forma, as ferramentas como o GitHub, Jira, Trello, VSTS, Jenkins, Puppet, entre outras, também podem ser configuradas para gerarem eventos de conversação dos bots. E com isso as ferramentas “avisam” os seres humanos sobre eventos importantes que devam ser monitorados.

Existem muitas ferramentas para realizarmos ChatOps, como por exemplo o HipChat, Flowdock e o  Campfire. Cito aqui o Slack como exemplo, ferramenta para chat entre seres humanos e robôs. Você pode imaginar ao usá-la que ela é similar ao Skype ou GoogleTalk, mas ela vai muito além. Por contar das integrações diversas com muitas ferramentas, ela permite  que times interajam com ela através de comandos para enviar ou receber notificações de ferramentas como o VSTS, Docker, Ansible ou Puppet.  Um exemplo simplista é mostrado na figura abaixo.

15-slash-command-example

E existe também a possibilidade de você integrar qualquer ferramenta nativa que possua na sua empresa através de ferramentas para o desenvolvimento de ChatOps. Um artigo com 12 frameworks da Nordic API fornece algumas boas opções para isso.

Um Modelo de Maturidade para Automação da Comunicação

Com esta definição de ChatOps, vamos caminhar em direção a um modelo de maturidade de infraestrutura como código

  1. Maturidade 1 – Inicial – Aqui não existe automação da comunicação. As ferramentas operam de forma silenciosa e também não aceitam comandos através de ferramentas de linha de comando e ferramentas de chats. O conceito de bots é desconhecido ou ignorado pelos times.
  2. Maturidade 2 – Consciente –  Aqui os primeiros experimentos de automação começam a acontecer. Neste nível, o time começa a usar integradores de uso trivial como IFTTT e o Zapier para fazer ferramentas como o Trello e JIRA conversarem com ferramentas de chats como o Slack ou HipChat.
  3. Maturidade 3 – Gerenciado – Aqui a automação da conversação ganha escala e existe forte comunicação das ferramentas de ciclo de vida com as ferramentas de chat nos pontos críticos dos processos. Além disso, os times começam a experimentar também o envio de comandos automatizados nas ferramentas de Chats para disparar processos automatizados de build, release e operação, entre outros. É esperado neste nível que todo o time de desenvolvimento passe a usar esta infraestrutura de comunicação.
  4. Maturidade 4 – Avançado – Neste nível, todo o ciclo de vida do desenvolvimento e operação de um produto está automatizado por conversações, seja dos humanos para as ferramentas quanto vice-versa. Neste nível, até produtos nativos foram personalizados e integrados na automação da comunicação com frameworks ChatOps. Aqui as equipes de infraestrutura também se sentem confortáveis para usar esta abordagem de comunicação.
  5. Maturidade 5 – Melhoria Contínua – Aqui existe excelência na comunicação entre humanos e máquinas e a sintaxe dos comandos é estendida para suportar conversações mais sofisticadas, até mesmo com uso de recursos de processamento de linguagem natural (NLP). O processo é continuamente aperfeiçoado e todo o time participa do processo do enriquecimento da aplicação. Os times de desenvolvimento e operações controlam o seu ambiente de forma muito mais ágil que times convencionais.

 

Recursos de Aprendizado

Alguns livros a respeito são indicados abaixo. O primeiro é uma introdução leve ao tema para os mais apressados. O segundo dá um tratamento um pouco mais extenso ao tema e o terceiro trata de aspectos mais avançados para aqueles que precisam criar e manter bots.

captura-de-tela-2016-12-19-as-19-42-46         captura-de-tela-2016-12-19-as-19-41-49

captura-de-tela-2016-12-19-as-19-35-38

O segundo livro está temporariamente disponível para download a partir do seguinte sítio.

Finalmente, recomendo também este vídeo de 36 minutos que conta a história do ChatOps no GitHub, organização que originalmente cunhou este termo.


E você, já conversou com um robô? Compartilhe aqui as suas experiência com ChatOps no mundo DevOps.

captura-de-tela-2016-12-19-as-19-45-47

 

Maturidade DevOps – Infraestrutura como Código

Conversando com uma pessoa que trabalha em uma grande empresa pública há alguns meses, ouvi o seguinte relato.

“Meu time precisava de um ambiente para a homologação do nosso produto, que já estava com um atraso considerável. Entretanto, ouvi da nossa infraestrutura que a requisição do ambiente de homologação demoraria algumas semanas. A partir deste momento, toda uma cadeia de estresses se estabeleceu de lado a lado, com pressões diversas de pessoas do desenvolvimento e respostas áridas do time de operações. E no final das contas, o nosso time precisou esperar 3 semanas para ter um ambiente liberado. E isso somente tornou o nosso projeto, que já estava ruim, em um pesadelo vivo”, – Gestor Irritado com a sua infraestrutura do século XX

Por mais estranha que esta história pareça, ela é ainda comum nas empresas que visito e nas empresas de meus colegas de TI. E, sim, algo está errado com isso. Com os avanços das últimas duas décadas nas tecnologias de virtualização e conteinerização, a engenharia de automação de infraestrutura pode emergir como uma disciplina.

Infraestrutura Programável

A Infraestrutura como código, ou infraestrutura programável, significa escrever código (que pode ser feito usando um linguagem de alto nível ou qualquer linguagem descritiva) para gerenciar configurações e automatizar o provisionamento da infraestrutura e implantações. Isso não é simplesmente escrever um scripts que sobe e roda uma máquina virtual, mas envolve também o uso de práticas de desenvolvimento de software testadas e comprovadas que já estão sendo usadas no desenvolvimento de aplicativos. Em suma, isso significa que você escreve código para provisionar e gerenciar seu servidor, além de automatizar processos que rodam neste servidor.

Observe o seguinte código abaixo, que pode ser executado no Windows, Linux ou Mac OS/X com uma ferramenta de provisionamento chamada Ansible.

- hosts: server
  sudo: yes
  sudo_user: root

  tasks:

  - name: Instala mysql-server
    apt: name=mysql-server state=present update_cache=yes

  - name: Instala dependencias
    apt: name=python-mysqldb state=present

  - name: Verifica se o mysql está rodando 
    service: name=mysql state=started

  - name: Criar usuario com os privilegios apropriados
    mysql_user: login_user=root login_password="" name={{ mysql_user }} password={{ mysql_password }} priv=*.*:ALL host=% state=present

  - name: Create base de dados AloMundo
    mysql_db: name=alo_mundo state=present

  - name: Copia o dump do SQL para a máquina remota
    copy: src=dumpAloMundo.sql.bz2 dest=/tmp

  - name: Restaura o dump no banco de dados AloMundo
    mysql_db: name=alo_mundo state=import target=/tmp/dump.sql.bz2

Este script (chamado de PlayBook no Ansible) instala o mysql-server na máquina remota (servidor), garante que o mysql está em execução, cria um usuário com a senha, cria o banco de dados alo_mundo, copia um dump sql para a máquina remota e o restaura no banco de dados destino.

Considere agora este exemplo, com o uso da ferramenta Docker.

  
docker pull microsoft/mssql-server-2016-express-window
docker run -d -p 1433:1433 
        -- env sa_password=senha 
        -- isolation=hyperv microsoft/mssql-server-2016-express-windows

Este script baixa um contêiner Docker de um ambiente remoto com um Windows e Microsoft SQL Server e o roda na porta 1433. E este contêiner pode ser rodado em um sistema operacional nativo diferente.

Observe que nos scripts acima você pode eliminar muito trabalho manual e permitir que o provisionamento de ambientes, instalação de softwares, configurações destes software e disparo de servidores seja todo automatizado em scripts.

Nos ambientes mais sistematizados e que requerem práticas ITIL podemos manter toda a governança necessária para o controle da infraestrutura. Ao mesmo tempo, eliminaremos o tedioso e lento trabalho manual que gera filas, atrasos e estresses para os times de TI.

Com esta definição em mãos, vamos caminhar em direção a um modelo de maturidade de infraestrutura como código

  1. Maturidade 1 – Inicial – Aqui não existe uma cultura de configuração e uso de scripts de provisionamento de ambientes. Todo o trabalho de preparação de ambientes é realizado diretamente sobre hardwares reais e isso é sempre repetido para cada nova requisição realizada para o time de infraestrutura. Nesta maturidade, os tempos de atendimento são longos e existe estresse frequente entre o time de desenvolvimento e o time de operações.
  2. Maturidade 2 – Consciente –  Aqui a cultura de virtualização começa a ser experimentada. Os times de operações adotam tecnologias como o Oracle VirtualBox, VMWare, Windows Hypervisor e similares para facilitar o trabalho de criação e configuração das máquinas. Alguns trabalhos são operacionalizados com scripts, mas o trabalho manual é ainda dominante e ainda gera tempos altos de atendimento das requisições.
  3. Maturidade 3 – Gerenciado – Aqui entram em cena ferramentas como Docker, Ansible e Puppet para tornar o trabalho de provisionamento, instalação e configuração de ambientes totalmente automatizados. Os scripts de provisionamento começam a ser escritos e organizados em repositórios de código. Com isso o atendimento de requisições de criação de ambientes é facilitado com tempos de atendimento reduzidos.
  4. Maturidade 4 – Avançado – Neste nível, os scripts são governados e podem ser distribuídos para os times de desenvolvimento para estabelecer ambientes self-service. Temos também o provisionamento dos ambientes de produção (Release Management) completamente controlados por máquinas e com mínima interferência humana. Para isso, são estabelecidos ambientes de nuvens privadas ou públicas para facilitar a implementação de políticas de escalabilidade e alocação de recursos em modelos de pagamento pelo uso. O efeito na redução do trabalho manual nos times de operações é notável.
  5. Maturidade 5 – Melhoria Contínua – Neste nível praticamente todo o trabalho de infraestrutura é gerido por código fonte e ferramentas de provisionamento. Máquinas virtuais, bancos de dados, servidores de aplicação, servidores Web e até mesmo redes (SDN) são configuradas por código fonte. O “hardware” se torna software.

 

Recursos de Aprendizado

Para quem nunca teve contato com a prática da InfraEstrutura como Código, isto pode parecer ficção. Felizmente, esta prática já é realidade em muitas empresas do Brasil. E ela pode ser operacionalizada por ferramentas gratuitas também, na sua empresa inclusive.

Deixo aqui alguns livros a respeito para o interessado em melhorar a gestão da sua infraestrutura e trazê-la para o século XXI. O primeiro explica a prática do IaC em detalhes os três outros livros apresenta ferramentas muito legais para operacionalizar esta prática.

51kktpbssjl    51otkrbt71l-_sx356_bo1204203200_

51piynh5ppl    51mweljjc4l


E como está a prática da infraestrutura na sua empresa? Já no século XXI ou ainda preso em algum túnel do tempo no século XX?

Se você não leu os dois primeiros artigos desta séria de Maturidade DevOps, deixo aqui os links:

Parte 1 – Maturidade DevOps – Qualidade de Código
Parte 2 – Maturidade DevOps – Gestão de Builds e Integração Contínua

 

Maturidade DevOps – Gestão de Builds e Integração Contínua

Este é o segundo post da série sobre maturidade em práticas DevOps. E aqui vamos discutir a maturidade na gestão de builds e integração contínua, prática nuclear dentro do mundo DevOps.

Antes de discutirmos a maturidade, é necessário esclarecer o que é um build. Na prática DevOps, um build é  um código executável gerado a partir de  instruções automatizadas e precisas de compilação a partir do código fonte e que atenda a um critério mínimo de testes.

Observe que esta definição tem duas implicações práticas:

  1. O código executável precisa ser gerado a partir de um arquivo chamado de definição de build para que possa ser compilado em qualquer ambiente. Isso evita a síndrome do desenvolvedor lambão que diz para você – “Na minha máquina compila”.
  2. O código executável deve passar com sucesso por uma suíte de testes automatizados para garantir sua estabilidade mínima (chamados de smoke tests). E isso evita a segunda síndrome do seu colega de trabalho, o desenvolvedor lambão, que diz para você – “Na minha máquina funciona”.

Com essa definição posta, podemos definir a nossa escala de maturidade.

  1. Maturidade 1 – Inicial – Aqui não existe uma cultura de builds. A compilação está acoplado às IDES como o Eclipse ou Visual Studio e é totalmente dependente destes ambientes. É comum que códigos compilem ou rodem em máquinas específicas apenas. Neste estágio também não observamos uma suíte de automação de testes que buscam garantir a qualidade do build.
  2. Maturidade 2 – Consciente –  Aqui a cultura de builds começa a ser instalada. Ferramentas como o Make, Maven, Gradle, Rake, Nuget e MSBuild começam a ser utilizadas pelo time para eliminar dependências de máquina na compilação. Isso permite que o código seja compilado com facilidade em qualquer máquina. Neste nível o time também introduz um suíte mínima de testes de fumaça (smoke tests) para garantir a estabilidade do build.
  3. Maturidade 3 – Gerenciado – Aqui os builds começam a ser executados em intervalos regulares em ambientes dedicados (ambientes de integração). Ferramentas como o Jenkins, GitLab, IBM Racional Team Concert, Ansible, Microsoft TFS ou Microsoft VSTS entram em cena para baixar do repositório os códigos fontes, compilar e testar os builds. Falhas na geração dos builds geram defeitos automatizados para o time de desenvolvimento. Neste nível também observamos uma maior cobertura  das suítes de testes (desejável maior que 20% do código fonte) e verificação automatizada das métricas de qualidade de código.
  4. Maturidade 4 – Avançado – Aqui temos um incremento na frequência de execução do build. Os builds começam a ser executados várias vezes por dia e operam até mesmo em ambientes paralelos com objetivos distintos (ex. Ambiente de build para testes de performance e ambiente de Build para testes funcionais). A cobertura do código fonte é agora expressiva e normalmente passa de 50% do código fonte e inclui testes funcionais e outros tipos de teste como performance, usabilidade ou segurança.
  5. Maturidade 5 – Melhoria Contínua – Aqui o time está tão avançado que ele começa a experimentar a prática da integração contínua (continuous integration), que formalmente definida é o processo de geração de builds disparado por modificações no código fonte. Em outros times, existem também políticas automatizadas que impedem o commit de código fonte que provoque quebra nos builds (padrão Gated Commit).

Podemos entender esta escala de maturidade a partir de dois fatores: frequência de execução e número de processos de qualidade executados. Um time com baixa maturidade não executa builds com frequência e não possui processos automatizados de qualidade que garantam o build gerado. Já um time de alta maturidade faz isso várias vezes por dia e cobre muitos processos técnicos tais como: testes de unidade, testes de tela, testes de integração, testes de segurança, testes de usabilidade, testes de performance, verificação da qualidade do código e até mesmo conformidade arquitetural a padrões pré-estabelecidos.

Naturalmente, este é um assunto denso e requer disciplina e tempo para ser implementado. Mas os resultados são notáveis e pagam, com juros, o esforço investido.

Recursos de Aprendizado

Se você deseja avançar a maturidade do seu time nesta importante prática, deixo aqui um conjunto importante de livros que são hoje referência para desenvolvedores profissionais. Os dois primeiros são específicos sobre a prática de Gestão de Builds, Integração Contínua e assuntos correlatos como a Entrega Contínua (Continuous Delivery). Temos aqui também dois livros sobre ferramentas populares – Jenkins e Microsoft VSTS. E finalmente dois livros sobre DevOps, sendo que o último é escrito na forma de uma história, o que torna a leitura bastante agradável.

51o9tzpyaul     41db4qikfil-_sx348_bo1204203200_
51ufxhdzvfl     41x0usghmnl-_sy346_

51mcvngdt6l   5170sr05qal


E você, ainda convive com desenvolvedores lambões? Ou já começou a aumentar a maturidade de gestão de builds no seu ambiente. Compartilhe aqui a sua experiência com esta prática.

 

Microsserviços e Outros Padrões de Arquitetura de Software

Desde que a Uber, Netflix e outras grandes empresas começaram a publicar as vantagens econômicas de produtividade e escalabilidade da adoção do padrão de microsserviços, este estilo arquitetural começam a ganhar muita atenção da comunidade técnica de TI. E isso ganhou ainda mais força com a publicação de um artigo de James Lewis e Martin Fowler sobre o tema.

Ao mesmo tempo, existe ainda muita confusão sobre este estilo, que é confundido com a criação de APIs, SOA ou ESB. Algumas distinções importantes incluem:

  • Cada microsserviço possui o seu próprio banco de dados;
  • Serviços trocam informações através de chamadas REST ou filas de mensagens; (e não através de protocolos WS-* ou com acesso ao banco de dados do serviço vizinho)
  • Não existe a figura de barramentos do tipo ESB (Enterprise Service Bus);
  • A governança dos serviços é executável, fornecida por ambientes de PAAS tais com o Azure ServiceFabric, Netflix OSS, CA API Gateway ou Pivotal Cloud Foundry.

Para ajudar a lançar luz sobre o tema e reduzir esta confusão, a Safari anunciou um minilivro gratuito sobre o tema de padrões de arquitetura de software do arquiteto Mark Richards. É um livro de leitura fácil e que possui figuras simples que permitem conhecer este padrão de microsserviços e também outros estilos arquiteturais tais como o estilo em camadas, baseado em eventos, microkernel e baseado em espaços (cloud architectures).

E, para aqueles que estão muito ocupados no momento para ler o livro, republico aqui a tabela final do livro com um comparativo das forças e fraquezas do padrões ao longo de seis critérios de análise.

captura-de-tela-2016-11-26-as-13-32-08