Aplicações em uso

Ao conceito de entrega de aplicações pelo time Blackops, categoriza-se as aplicações de terceiros, não desenvolvidas pelo time, porém, que tiveram um ambiente preparado e configurado internamente para funcionamento pleno e conjunto com as aplicações desenvolvidas, ou que estão no ambiente da SETIC .

Dentre as aplicações entregues, objetiva-se:

• Melhoria contínua
• Manutenibilidade de código
• Escalabilidade
• Integração
• Versionamento
• Controle de recurso
• Separação de ambientes
• Metrificação de qualidade
• Medição de segurança

Para alcançar os pontos citados, foram testadas diversas ferramentas em diferentes ambientes, onde foram realizados inúmeros testes como carga, segurança, estresse, velocidade e etc.

Gitlab

 

GitLab é uma plataforma de desenvolvimento de software ponta a ponta de código aberto com controle de versão integrado, rastreamento de problemas, revisão de código, CI / CD e etc…

O Gitlab da SETIC é hospedado nos próprios servidores da secretaria, porém, a ferramenta possui a possibilidade de hospedagem em um contêiner ou em um provedor de nuvem.

Embora a ferramenta tenha funcionalidades pagas, todas as funcionalidades utilizadas na SETIC, se encaixam no escopo gratuito da ferramenta, não havendo até o momento nem uma necessidade na aquisição de funcionalidades pagas, sendo isto possível através de um ambiente multi-ferramental.

 

Branch (Ambientes)

 

Uma “branch” é uma linha independente de desenvolvimento em um projeto.Quando você cria uma nova branch (em seu terminal ou com a interface da web), você está criando uma “ramificação” instantânea de uma determinada branch, possuindo exatamente tudo que a branch original possuía, porém, qualquer mudança realizada nesta nova ramificação, não irá alterar a original, geralmente esta sendo a branch master, em seu estado atual.

A partir daí, você pode começar a fazer suas próprias alterações sem afetar a base de código principal. O histórico de suas alterações será rastreado em sua branch, no caso sua “ramificação”. Quando as alterações estiverem prontas, você poderá mesclá-las com o restante da base de código com uma solicitação de mesclagem ou “merge”.

Em conjunto com o conceito de Branch, a SETIC emprega a prática de separação de ambientes, sendo eles: Dev (desenvolvimento), QA (homologação ou testes em ambiente de produção), Master (produção, versão final que será utilizada pelo cliente). Na branch Dev, os desenvolvedores podem criar funcionalidades, executar testes e mudanças, e aplicar dados, sem o risco de que a aplicação em produção sofra danos estruturais ou arquiteturais, bem como conflitos e erros. Isto é possível pois esta ramificação é um clone, ou, uma instância interna onde o acesso só é permitido na secretaria por membros dos times, essa ramificação é direcionada para os desenvolvedores.

Na Branch QA, os desenvolvedores mesclam as funcionalidades feitas no ramo Dev a partir do critério de testes, qualidade, capacidade de execução e funcionalidade, permitindo assim que a QA se torne um clone inicial da versão final do Dev. Este ramo é direcionado para os Product Owners, sendo este um representante das funcionalidades requisitadas, podendo assim realizar testes e executar rotinas para validar se os pontos entregues estão em conformidade com os pontos pedidos.

A Branch Master é o ramo final, essa branch é o clone da versão final aprovada de QA, é esta branch que será para uso do cliente para suas finalidades, toda e qualquer mesclagem para essa branch só é permitida através de verificação e aprovação prévia, pois a mesclagem de uma versão com erros poderá acarretar no mal funcionamento da aplicação em suas funcionalidades.

 

CI/CD

 

A integração contínua (CI - Continuous Integration) é uma estratégia de desenvolvimento de software que aumenta a velocidade de desenvolvimento, garantindo a qualidade do código que as equipes implantam. Os desenvolvedores enviam (commit) continuamente o código em pequenos incrementos (pelo menos diariamente, ou mesmo várias vezes ao dia), que é então criado e testado automaticamente antes de ser mesclado com o repositório compartilhado (Branch Dev para QA, ou QA para Master). 

 

Integração contínua

Cada desenvolvedor envia commits (“savestates” do código atual na branch atual) diariamente, ou até mais frequentemente, em um repositório de código principal compartilhado. Cada confirmação aciona uma compilação e teste automatizados da base de código. Se a compilação ou qualquer teste falhar, ele é reparado rapidamente, muitas vezes em minutos. A integração contínua trabalha lado a lado com as metodologias Ágeis. Os membros da equipe trabalham em “histórias” incrementais e o código para essas mudanças de software é mesclado incrementalmente no repositório de software compartilhado várias vezes ao dia.

A integração contínua pode ser usada para muitos tipos de projetos de software. Por exemplo: O desenvolvedor ou editor de conteúdo cria um novo branch de código, atualiza o HTML na página e, em seguida, confirma as alterações.

Quando o desenvolvedor conclui todas as alterações no branch específico, ele cria uma solicitação pull (pull request) no Gitlab. O Gitlab está integrado ao Sonarqube e Openshift. ambas as ferramentas executam os processos de construção no código e, em seguida, executa os scripts de teste automatizados.

Se o Sonarqube encontrar algum erro (status de compilação vermelho), o desenvolvedor será notificado e a mesclagem ou pull será interrompido. Caso contrário, o usuário é notificado de que a construção foi bem-sucedida (verde) e que o código foi enviado para o servidor. Isso permite que o desenvolvedor visualize a página da web. Depois de verificado, o desenvolvedor pode mesclar a nova ramificação do código na produção.

Qual é a diferença entre integração contínua, entrega contínua e implantação contínua (deploy)?

Integração contínua - A construção e teste automatizados de seu aplicativo a cada novo commit.

Entrega contínua - Um estado em que seu aplicativo está sempre pronto para ser implantado. Uma etapa manual é necessária para realmente implementar o aplicativo.

Implantação contínua ou deploy contínuo (Continuous deployment) - A automação de construção, teste e implantação. Se todos os testes forem aprovados, cada novo commit enviará um novo código por meio de todo o pipeline de desenvolvimento para a produção, sem intervenção manual.

 

YML

Tanto a integração com as ferramentas SonarQube e Openshift, quanto a configuração geral de todo o Pipeline CI/CD do Git, são possíveis através do arquivo de configuração de extensão “.yml” presente nos projetos da secretaria. Nele são configurados os steps (passos) de execução de todo o processo do pipeline, desde o commit do desenvolvedor, até a implantação da funcionalidade para a produção.

Sonarqube

 

SonarQube é uma ferramenta automática de revisão de código para detectar bugs, vulnerabilidades e “code smells” no código, integrado ao ao seu fluxo de trabalho da SETIC para permitir a inspeção contínua de código em todas as ramificações do projetos projetos e solicitações de pull.

A ferramenta SonarQube, foi implantada na SETIC em  instância local opensource para analisar os projetos dos times de desenvolvimento, e integrada ao Pipeline CI/CD do Gitlab.

 

Análise

 

A análise do código começa após a instalação e configuração de um scanner SonarQube. O scanner pode ser executado em seu build ou como parte de seu pipeline de integração contínua (CI), realizando uma varredura sempre que seu processo de build for acionado.

Analisando Branches

Começando na Branch Dev, os desenvolvedores podem analisar seus branches no SonarQube e garantir que a qualidade do seu código seja consistente em todo o caminho até o nível do branch em seus projetos.

Analisando pull requests

O SonarQube sob o ambiente da SETIC permite a integração do SonarQube para fazer parte do processo de solicitação de pull (pull request) ou mesclagem (merge). A emissão de uma solicitação pull pode acionar uma análise de branch e adicionar o “relatório” ao pull request para ver sua análise de branch diretamente na interface do ALM, além da interface SonarQube.

 

Duplicidade

 

Durante a análise do código o Sonar busca por funcionalidades poderiam ser unificadas e reutilizadas, funções/classes/pacotes que possuem a mesma finalidade e etc. Quando se esbarra em uma duplicação o Sonar adiciona o alerta a interface de métricas colhidas.

Openshift

 

O OpenShift é uma plataforma de código aberto desenvolvida pela Red Hat que auxilia no processo de orquestração de containers baseada em Kubernetes e containers Linux de maneira independente da plataforma na qual os containers serão executados.

Através de uma interface muito amigável e intuitiva, o OpenShift oferece a possibilidade de controlar todo o ciclo de vida de uma aplicação baseada em containers, desde o deploy até a execução efetiva.

Isso é possível graças a integração facilitada com várias outras ferramentas e SDKs para diferentes linguagens, o que torna o OpenShift uma ferramenta muito competente e completa não somente para o gerenciamento de containers, mas também para o controle de todo o ciclo de vida de uma aplicação.

A estrutura estabelecida na SETIC faz uso da ferramenta OKD. O OKD é basicamente uma distribuição “personalizada” do Kubernetes. OKD é um acrônimo para “Origin Kubernetes Distribution”. O OKD foi criado pela Red Hat para que existisse uma distribuição do Kubernetes mais otimizada para processos tradicionais em ambientes baseados em nuvem, como aplicações multi-tenancy e aplicação de processos de continuous delivery/continuous integration. Ou seja: o OKD é um Kubernetes otimizado para as situações previamente citadas, otimizações estas realizadas pela Red Hat.

O OKD não é concorrente do OpenShift. Na verdade, o core do OpenShift é justamente o OKD. A estrutura baseada em Kubernetes que é utilizada pelo OpenShift é, na verdade, o OKD. Sendo assim, a estrutura da SETIC utiliza o OKD de maneira direta, ou seja: sem passar necessariamente pelo OpenShift.

O OpenShift funciona em cima de um sistema baseado em camadas, onde cada camada é responsável por determinada funcionalidade. A sobreposição destas camadas é que faz com que o OpenShift consiga oferecer a quantidade de funcionalidades que são oferecidas.

 

Escalabilidade

 

Escalabilidade é a possibilidade de realizar upgrades de recursos sempre que necessário, com isto a SETIC possui a capacidade de poder criar e remover instâncias de suas aplicações conforme a demanda: novos containers são criados ou removidos conforme o número de usuários cresce ou diminui na utilização da aplicação. As funcionalidades do OpenShift permitem que o trabalho de distribuição de recursos de hardware sejam executados automaticamente, direcionando o fluxo computacional para as áreas que mais demandam. Dessa forma, o time de desenvolvedores e infraestrutura pode focar no que é mais importante sempre.

 

Alta disponibilidade

 

Resiliência em caso de falha em um dos pontos (nós) da estrutura, ou seja é projetado para trabalhar tanto em infraestruturas de cloud computing, multicloud ou mesmo servidores locais. Os gestores podem migrar aplicativos entre todos esses tipos de plataformas facilmente com o apoio de um modelo que reduz interferências e as chances de uma informação ser corrompida durante a migração. Assim, o gestor consegue garantir o máximo de disponibilidade para os seus usuários.

 

Deploy / Build

 

Build - construção do código desenvolvido, neste caso é possível compilar o código em seu estado utilizável funcional em um “encapsulamento de entrega”.
 O Source-to-Image (S2I) é uma ferramenta criada para construir imagens Docker reproduzíveis. Ela produz imagens prontas para serem executadas injetando a fonte da aplicação dentro da imagem Docker existente e montando uma nova. Esta nova imagem incorpora a imagem-base (builder) e a fonte construída. Ela vem pronta para utilização com o comando de execução do Docker. O Source-to-Image suporta construções incrementais, que reutilizam dependências que já foram baixadas e artefatos construídos anteriormente.

Deploy - entrega da construção em formato utilizável por docker. O fluxo de imagem é uma abstração que permite ao OpenShift fazer o deploy das aplicações a partir de um registro público de imagem, ao mesmo tempo em que, dinamicamente, faz o deploy de novas versões de imagens conforme elas entram para o registro. É possível fazer configurações de build e deploys para ver fluxos de imagem e atualizá-los automaticamente quando novas versões de imagens estiverem disponíveis.

 

Gerenciamento de Aplicações

 

Disponibilização de interface para gestão das aplicações na estrutura da SETIC.O Red Hat OpenShift tem mecanismos para a gestão que tornam o trabalho de distribuição de aplicativos na nuvem muito mais simples. A orquestração dos containers contém mecanismos para a comunicação entre eles, evitando falhas na troca de dados entre eles.

Da mesma maneira, é possível definir configurações (antes no hardware) de modo flexível. O gestor consegue compartilhar espaço de armazenamento, recursos de rede e IP a partir das suas demandas. Dessa forma, o OpenShift consegue auxiliar empresas a ter aplicativos mais leves e com maior performance do que os utilizados em plataformas de máquinas virtuais.

 

Webhook

 

É a automação que permite a realização do build / deploy com as últimas modificações realizadas no código (latest merge / pull).

Após o desenvolvedor submeter o seu código para um determinado “ramo”, o web hook “pesca” esse código para o conjunto de esteira designado, neste caso o openshift. Abstraindo assim a necessidade de o fazê-lo manualmente.