DevOps

A fusão do Desenvolvimento (Dev) com as Operações (Ops), o DevOps, é o seguimento natural do Agile.

O primeiro princípio do manifesto para o desenvolvimento ágil de software^[1] já deixava claro que “our highest priority is to satisfy the customer through early and continuous delivery of valuable software”: a maior prioridade é a entrega rápida e contínua de software valioso para o negócio.

Esta parece uma proposição neutra e universalmente válida, até nos apercebermos de quão distante está das práticas correntes das organizações.

A relação entre as tecnologias de informação (o IT) e as operações (o negócio) nunca foi pacífica. Representado por departamentos de sistemas de informação internos ou por fornecedores externos, o IT tradicional (pré DevOps) tem assumido posições pouco flexíveis, demorando muito tempo a dar resposta às aspirações das áreas que utilizam as suas soluções. E as áreas operacionais tendem a não transferir o seu conhecimento de processos e práticas para o IT, sendo certo que, a maior parte das vezes, o IT tradicional não aprecia e reage negativamente a estas sugestões, que considera “excessiva” customização^[2].

No fluxo contínuo de criação de valor para o cliente, é necessária uma muito melhor colaboração entre as muitas funções envolvidas, isto é, uma reengenharia de processos que inclua também o IT.

O DevOps advoga a constituição de equipas conjuntas e diretas, solidariamente responsáveis, sem intervenção de terceiros.

Os terceiros habitualmente convocados (o Quality Assurance^[3], uma coordenação, uma fiscalização de projeto) para criar uma ponte entre Dev e Ops, na prática destroem a nova relação de confiança que a cultura DevOps pretende instituir entre o desenvolvimento e as operações. E destroem, inevitavelmente, porque a sua única razão de existência é o pressuposto de essa confiança estar ausente^[4].

Na cultura DevOps, a organização do desenvolvimento de software já não é por projeto, mas como um serviço contínuo que

• deteta (e até antecipa) novas necessidades do cliente e modela os novos requisitos,
• converte estes requisitos, rápida e imediatamente, em código,
• integra, testa e garante a coerência de todas as componentes e do trabalho desenvolvido em paralelo por várias equipas,
• entrega ou disponibiliza a nova versão ao cliente e
• (a pedido ou após validação) coloca a nova versão em utilização produtiva pelo negócio / operações (Ops).

A comunidade DevOps, bastante forte, organiza todos os anos o All Day DevOps, um evento que, seguramente, vale a pena acompanhar e consultar os conteúdos ds sessões dos anos anteriores^[5].

O relatório da Puppet sobre o estado atual do DevOps (2018 State of DevOps Report)^[6] é também uma referência útil.

A contribuição da Quidgest para o DevOps

O Genio é um fator decisivo na garantia de automatização de todo este processo.

Sem o Genio, o DevOps sofre de uma de três limitações

• apenas começa na integração contínua e não inclui a fase de exploração de novos requisitos,
• ou não tem forma de modelar esses novos requisitos
• ou, entre a exploração / modelação e a integração contínua exige um esforço considerável de programação manual, sendo um facto que a programação manual estrangula o fluxo DevOps e acaba por deteriorar os seus resultados pretendidos.

O fluxo do DevOps pode ser mais lento ou pode ser mais rápido. Sendo a rapidez, naturalmente, o objetivo mais desejável e a vantagem competitiva a alcançar. De pouco vale dizer-se que se adota esta perspetiva se os tempos de disponibilização de versões melhoradas pelo desenvolvimento (Dev) às operações (Ops) permanecem muito longos.

O Genio da Quidgest contribui decisivamente para o sucesso desta perspetiva, ao interligar todo o processo:

• modela os requisitos,
• programa de forma automática e extremamente rápida o código,
• integra o trabalho de várias equipas (através do GenioSVN),
• prepara, testa e entrega (através de ferramentas open-source como Jenkins, a que a Quidgest pode recorrer, ao contrário de outras plataformas, por usar exclusivamente linguagens de programação padrão),
• assegura a evolução automática da estrutura de dados e documenta, informa e prepara os utilizadores finais de modo a garantir a utilização produtiva da nova versão da solução.

O DevOps requer a existência de architecturally significant requirements. Na Quidgest, esses requisitos foram transformados em padrões, constituindo o conjunto de padrões relacionados com a engenharia do software.

O processo de integração requer uma ferramenta de controlo de versões (na Quidgest, o GenioSVN), com todas as funcionalidades associadas a repositórios, checkouts, baselines, updates, commits, gestão de conflitos, lista de mudanças, branches ou forks, revisão pelos pares e responsabilização (blame).

O Genio suporta um outro aspeto muito importante, que é a evolução em paralelo de duas camadas do modelo: o modelo de negócio (estrutura de dados, regras de negócio, interfaces e processos) e a tecnologia (arquiteturas, linguagens de programação, bibliotecas, padrões). Estas duas camadas garantem a continuidade e a integração de todo o processo.

Num processo de integração contínua, a evolução é também contínua. Tal garante 1) vidas úteis das soluções muito mais prolongadas e 2) inexistência de disrupções pela mudança de versões do software.

Os nossos clientes e parceiros na co-inovação, nomeadamente os que anualmente premiamos no Q-Day, são um bom exemplo de aplicação prática de DevOps a grandes sistemas de gestão.

___________________

[1] http://agilemanifesto.org/principles.html
[2] A revista QuidNews nº 10 ilustrava, com uma pequena história “O aleijadinho e o alfaiate”, a páginas 25, o que a Quidgest pensa deste conceito de excessiva customização.
[3] O diagrama que, a esta data, ainda figura na página wiki correspondente https://en.wikipedia.org/wiki/DevOps#/media/File:Devops.svg ainda inclui o QA na equação, o que não nos parece fazer qualquer sentido
[4] Uma posição muito próxima é defendida por Asaf Yigal https://devops.com/devops-killed-qa/
[5] Disponíveis em https://www.alldaydevops.com/2017-all-day-devops-video-recordings Por exemplo “It’s Not Continuous Delivery If You Can’t Deploy Right Now”, por Ken Mugrage
[6] Publicado a 12 de setembro de 2018.