Tag: DevOps

VSTS – Pipeline de releases e gestão da mudança com aprovadores

1 Comment

Contexto: já vimos os benefícios e desafios dos processos de CI (Continuous Integration) e CD (Continuous Delivery) em outros posts. Além de habilitar esteiras velozes e eficientes para publicação de releases, é um dos pontos determinantes na adoção de práticas DevOps na empresa.

Este post é direcionado as empresas que possuem processos mais formais, regidos por compliance. O release neste caso depende de aprovações como do gestor da mudança (change management) e outras áreas, como a homologação do solicitante (geralmente o Product Owner), antes de ir para a produção.

VSTS – Configurando aprovações no pipeline de releases
Iniciamos criando uma nova definição de release. Para isso, acesse o VSTS na opção de Build and Release. Em Releases, clique em + Create Release Definition. A janela abaixo será aberta com as configurações da release. Escolha os ambientes (environments) e artefatos que serão trabalhados.

release

Em seguida, todas as Releases criadas serão exibidas na tela. Neste exemplo já haviam outras releases criadas, por isso apareceram várias. Clique em Edit para configurar o Pipeline com os Artefatos e Tarefas da release.

releases.png

O Pipeline habilita a configuração Artefato (na esquerda) e dos Ambientes (na direita). É nesta área que definimos os aprovadores, triggers e agendamento das tarefas.

pipeline-releases

Artefato
Ao adicionar um novo artefato, escolha o tipo do artefato – Build | Source Control | etc., referencie o nome do projeto e as definições de Build (por termos escolhido o Build no source type). 
artifact-release

Environments
Ao adicionar os ambientes em + New Environment, podemos criar por exemplo, os ambientes de desenvolvimento, homologação e produção. Utilize a opção clone environment após a criação do primeiro ambiente para copiar as configurações (se aplicável) a fim de facilitar.

Com os ambientes criados, clique na própria caixa do ambiente para configurar as tarefas que serão executadas pelo Agent (lado direito da imagem abaixo).

release-environments

Também na configuração do ambiente, mas no canto esquerdo da caixa há uma imagem que representa triggers e aprovadores para pré ou pós deployment. Clique nela:
trigger-approval

Em seguida, será exibida uma tela com a configuração de Pre-deployment:

  • Triggers: define se o evento acontecerá After release | After Environment | Manual Only
  • Pre-deployment approvals: insira os usuários que precisam aprovar a release antes de subir em produção, ou mesmo no ambiente de QA.
  • Schedule: se o build (que inicia a execução das releases) não estiver automático, esta opção permite agendar a execução das releases.

 

O acompanhamento do deploy das releases está disponível na aba Logs. O status de cada etapa e em qual ambiente está sendo executado pode ser visto no lado esquerdo da tela.release-log

As aprovações podem ser gerenciadas na guia Summary da conta do aprovador. Ao clicar em Approve or Reject, será aberta a janela para realizar a aprovação.

release-approval

Definições de Build – Continuous Integration (DevOps)

2 Comments

Por aqui vamos demonstrar o passo-a-passo das definições de Build, utilizando o VSTS da Microsoft para criar o workflow com as tarefas de Integração Contínua (Continuous Integration) no time de desenvolvimento.

Acesse o VSTS no Projeto que será feita a configuração de Build, utilizando o caminho Build and Release > Builds. O botão + New cria um novo workflow para configurar as definições de Build.

Get sources
O primeiro passo é configurar o versionador de código (TFVS | GitHub | Subversion | etc.) e Workspace Mappings (Map | Cloak) com o caminho de execução dos Builds do projeto.

Build-definition-I

NuGet
O NuGet é um package management compatível com plataforma Microsoft e contém o código compilado (DLLs),  trabalhando com bibliotecas e ferramentas do Visual Studio. Os pacotes podem ser publicados em host público ou privado. Nesta fase, somente indicar o local (path) da Solution do projeto, conforme abaixo:

Build-definition-II

Visual Studio Build
A configuração do Build é simples, basta indicar o path da Solution do projeto.

Build-definition-III

Visual Studio Test
Esta tarefa é sensacional para o CI. O Visual Studio Test permite executar testes unitários, code coverage, entre outros. Neste link há mais detalhes sobre esta task.

Neste exemplo, selecionamos o Test Assemblies, relacionando as DLLs e o caminho do projeto de teste da solução. Também habilitamos o Code Coverage Enabled para analisar a proporção de código que está sendo coberto por testes, como testes unitários.

Build-definition-IV

Index Sources & Publish Symbols
O Symbol Servers habilita os debuggers para retornar automaticamente o correto symbol files sem conhecimento do nome do produto, número do build ou nome do pacote. Veja mais em Publish Symbols for debugging.

Build-definition-V

Code Analysis
O VSTS analisa o código gerenciado de duas maneiras:

  • Static Analysis of Managed Assemblies – FxCop: fornece informações para corrigir problemas com violações de programação e regras de design.
  • . Net Compiler Platform Analyzers – Roslyn: analisa qualidade, estilo, facilidade de manutenção, design e outros problemas de código. Muitas regras da análise de código estático já foram reescritas na análise Roslyn e podem substituir a análise estática para código gerenciado.

Em nosso exemplo, definimos a regra de Minimum Recommended Rules que atua nos problemas mais críticos do código. A descrição de todas as regras podem ser encontradas na documentação da Microsoft.

Build-definition-VI

O check-in do código pode ser configurado com política para prevenir que o desenvolvedor faça check-in sem ter executado a análise do código. O SonarQube também é uma ótima ferramenta de análise do código e pode ser integrada com o VSTS.


Publish Build Artifacts
E na última etapa somente a configuração do local onde será publicado o artefato.

Build-definition-VII

 

Referências
– Get Sources – Cloak
– Nuget with VSTS
– Visual Studio Test
– Code Analysis – Microsoft
– Publish Symbols for debugging
– Publish Build Artifacts – Microsoft

Jornada DevOps

4 Comments

DevOps
Tudo começou em uma Palestra no Velocity 2009 – San Jose – CA – sobre 10+ Deploys per day. John Allspaw & Paul Hammond apresentaram os dilemas do modelo tradicional de desenvolvimento: “Dev’s job is to add new features; Ops’ job it to keep the site stable and fast” e como habilitar o modelo operacional para atender as mudanças nos negócios.

As falhas de aplicação, erros operacionais e downtime estão entre os principais motivadores para a evolução do processo entre desenvolvimento e operações. Algumas práticas como infraestrutura automatizada, controle de versionamento, métricas, respeito e confiança foram recomendadas para aproximar as áreas de Business, Dev e Ops.

devops-velocity.png

Já nos dias atuais, o conceito de DevOps evoluiu, assim como as ferramentas que utilizamos. Não há uma entidade ou comitê responsável pelo tema, por isso compartilho as duas definições que entendo como as mais interessantes:

By Microsoft: “DevOps é a união de pessoas, processo e produtos para habilitar a entrega contínua do valor para nossos usuários finais. A contração de “Dev” e “Ops” faz referência à substituição da estrutura fechada de Desenvolvimento e Operações para criar equipes multidisciplinares que agora trabalham juntas com práticas e ferramentas compartilhadas e eficientes. As práticas essenciais de DevOps incluem planejamento ágil, integração contínua, entrega contínua e monitoramento de aplicativos”.devops-microsoft.png

By Amazon: “O DevOps é a combinação de filosofias culturais, práticas e ferramentas que aumentam a capacidade de uma empresa de distribuir aplicativos e serviços em alta velocidade: otimizando e aperfeiçoando produtos em um ritmo mais rápido do que o das empresas que usam processos tradicionais de desenvolvimento de software e gerenciamento de infraestrutura. Essa velocidade permite que as empresas atendam melhor aos seus clientes e compitam de modo mais eficaz no mercado”.

DevOps-AWS

E para iniciar a Jornada DevOps na sua organização, será necessário conhecer e evoluir algumas áreas de conhecimento do ciclo de vida da aplicação, transformando o mindset da equipe na adoção de:

  • Práticas: Integração Contínua (CI), Entrega Contínua (CD) e Implantação Contínua (CD) para colocar releases em produção continuamente. A esteira rápida propicia a aprendizagem validada e correções de bugs rapidamente
  • Controle de versão: GIT ou TFVC são ferramentas no processo de gestão de fontes que garantem a rastreabilidade e versão correta de implementações e correções
  • Gestão de projetos ágeis: o SCRUM, por exemplo, possui template no VSTS e permite criar o backlog da sprint na ferramenta. O método ágil também habilita o time de desenvolvimento a ter rápida adaptação a mudanças
  • Monitoramento: acompanhar as releases em produção e funcionamento do sistema mediante períodos sazonais ou larga escala. Lembre-se que o ciclo de vida da aplicação não termina ao colocar o sistema em produção

devops-cycle

  • Cloud: ótimo enabler ao Load Balance e Auto Scaling. As aplicações precisam crescer sob demanda. O modelo de validação de negócio do Lean Startup propõe a contínua validação do mercado para justificar um aumento de infra
  • Infraestrutura como código: gestão de ambientes com agilidade para atender o negócio e o time de desenvolvimento
  • Container: evoluindo das máquinas virtuais, tornando a gestão de SO mais leve e fácil
  • Arquitetura: escalabilidade e eficiência para não manter os sistemas acoplados


Benefícios

  • Velocidade: entrega contínua de novas funcionalidades (time-to-market) e resolução rápida de problemas
  • Confiabilidade: baixa taxa de falhas; monitoramento e log das implementações
  • Escalabilidade: a automação de processos (deploys etc.) e a infra as code possibilitam escalar as aplicações conforme demanda
  • Melhoria na qualidade do código-fonte: não permite subir código ruim para produção
  • Redução de Lead time
  • Mais tempo para inovação (ao invés de corrigir e manutenção)
  • Ambientes operacionais estáveis
  • Integração entre as áreas de desenvolvimento e infraestrutura

Desafios e questionamentos
… mudança cultural e de mentalidade (equipes tradicionalmente separadas em silos)
… simplificação e automação de processos
… já existe o papel do Configuration Manager na equipe?
… sua equipe de infraestrutura tem maturidade com scripts e códigos?
… trabalhamos com métodos ágeis e ferramentas de apoio?
… e as questões de compliance?
… a segurança da informação será melhorada?
… quais as métricas de desempenho?
… preferencialmente realizar um projeto piloto

Referências

VSTS – Etapas de aprovação em Deployments

1 Comment

Objetivo: criar etapas de aprovação na promoção de binário entre ambientes. Os ambientes podem ser configurados e geralmente tratam-se de desenvolvimento, homologação, QA e produção.

Contexto: organizações que possuem um processo mais formal de publicação de releases no ambiente de produção, seguindo compliance e aspectos verificados em auditoria como SoD – segregação de funções (por exemplo: desenvolvedores não podem acessar o ambiente de produção), aprovadores da mudança (que será publicada em produção) e homologação da mudança (pelo solicitante).


Criando etapas de aprovação

O primeiro passo é criar as condições para a promoção do binário em um ambiente determinado. No exemplo abaixo (lado esquerdo da imagem), escolhemos o servidor de Pré produção, clicando no botão Pre-Deployments Conditions:

pre-deployment

A opção “Select trigger” (lado direito da imagem) apresenta as três possibilidades (After release | After environment | Manual only). Escolha a trigger “After environment” para que o deploy ocorra depois do ambiente anterior.

Habilite a opção Pre-Deployment Approvers para selecionar os usuários que irão efetuar a promoção dos binários entre os ambientes:

pre-deployment-conditions

 

 

Mindmap (Mapa Mental) DevOps – principais tecnologias

2 Comments

Olá!

Neste POST vamos apresentar o Mindmap DevOps com as três principais tecnologias ou conceitos de cada área de trabalho. O Mapa Mental auxilia a compreensão das frentes em que a organização precisa estruturar ou simplesmente adequar para adotar as práticas DevOps.

Para quem está iniciando a trajetória neste universo, sugiro uma leitura dos tópicos sobre ALM / DevOps e entender como tudo isso se encaixa.

Mindmap-devops

VSTS – Processo de Release

Contexto: criar e configurar o processo de Release dentro do VSTS, gerenciando os artefatos e pipelines

Leitura recomendada: recomendo a leitura do artigo VSTS – Build e Release para entendimento do processo de Build e Release utilizando o VSTS

Criando o Processo de Release

O primeiro passo para criar um novo processo de Release é acessar o Visual Studio e escolher a opção “Releases” dentro do Menu “Build and Release”.

No canto esquerdo, clique no botão “+” e escolha a opção “Create release definition“. release-definition

E então é criada a Pipeline para a publicação dos binários:release-pipeline

Escolha o template que será utilizado para o projeto ou a opção “Empty Process”. Defina o nome para o ambiente que será feito o deploy no servidor e os owners do ambiente.release-environment

Adicionando o artefato de Build

A etapa posterior é testar os binários nos ambientes. Para isso, devemos adicionar o Build que será promovido nos ambientes. No Pipeline de Release, clique em “+ Add Artifact” e selecione o Build que será promovido no Pipeline de Release:

  • Source Type: escolha a opção Build
  • Project: (defina o nome do projeto que será utilizado)
  • Source (Build Definition): será o Build da última versão desenvolvida
  • Clique em Add…

release-artifact

 

Adicionando Tasks nos ambientes

E agora podemos adicionar as Tasks em cada um dos servidores. Para isso, acesse a Release criada (clicando no nome da Release) > Environments. Clique no link para adição / edição das tasks:
release-environments

Em Agent Phase, defina os seguintes parâmetros:
release-agent-phase

E em “+” para adicionar uma nova Task:
release-agent-phase-I

 

Em Add Tasks, no campo Search, digite Tokenize:
tokenize
Caso a task não esteja instalada no seu VSTS, ela deve ser baixada através do Market Place. Ela tem por objetivo mudar as linhas do Web.confg de acordo com o ambiente.  Clique em Add para adicionar a task e configure a task de Tokenize:
tokenize_I

Na aba Variables, podemos configurar as variáveis de ambiente oriundas do Web.Config
release-web-config

Em seguida, adicione uma Nova Task chamada Windows Machine File Copy e configure os parâmetros abaixo:
windows-machine

No VSTS existe a possibilidade de clonar os ambientes afim de aproveitar as configurações prévias. Para isso vá ao Pipeline > Environments > e clique em Clone. Será criado um novo ambiente para promoção do binário. Assim, teremos a esteira pronta para os servidores.
esteira

 

VSTS – Build e Release – DevOps

1 Comment

Objetivo: descrever a importância do Build e Release no processo de DevOps

Contexto: colocar um novo sistema em produção (ou incremento) é uma demanda frequente nas organizações que trabalham com desenvolvimento de sistemas. Não pode haver bottlenecks! Há um constante monitoramento para checar se os usuários estão realmente utilizando as releases e o que podemos fazer para melhorar a experiência do usuário.

Tudo isso exige um processo de Continuous Integration / Delivery / Deployment. As práticas de DevOps, incluindo a configuração de Build e Release, são essenciais para melhorar a qualidade, controle e integração dos sistemas a serem publicados. Evitar versões erradas em produção e a famosa frase do desenvolvedor “na minha máquina funciona” são dilemas que as empresas mitigam com um bom modelo de versionamento e gestão de fila da implementação.

E assim, desde a criação de máquinas de Build até a transição nos servidores de DEV, QA, Homologação, Pré-produção e Produção, compartilho no post abaixo uma orientação de configuração de Build e gestão dos artefatos no ambiente VSTS.


Build e Release

O processo de Build envolve funções de integração, construção, versionamento, qualidade e compilação do código-fonte produzido. As ferramentas VSTS, Maven e GitHub são utilizadas para auxiliar na integração e monitoramento dos artefatos. Quando há quebra no Build devido a problema neste processo, os desenvolvedores precisam corrigir e fazer o check-in novamente. O processo de integração contínua e o apoio da infraestrutura são necessários para manter a esteira de publicação rápida, principalmente para organizações que trabalham em larga escala.

Posteriormente, o Release é a liberação da nova versão do sistema em produção. Considera-se que no Build já tenha sido avaliado e testado a qualidade para garantir que não haja erros. Este processo consome recurso de servidores, que dependendo da complexidade, exige escalabilidade para realizar o deploy do código.

Para automatizar as etapas do processo de Build e Release e envio dos scripts ao repositório, os times geralmente utilizam ferramentas como Jenkins. Outros aspectos a serem considerados:

  • Criar servidor(es) para execução de Builds
  • Automatizar etapa de compilação e deploy
  • Ambientes (Dev | QA | Homologação | Produção)
  • Processo de qualidade para validação do negócio
  • Testes automatizados
  • Padrnoização de regras para arquitetura
  • Utilização de teste unitário, Sonarqube (qualidade do código) e práticas como BDD ou TDD


Utilizando VSTS

Build
Acesse o VSTS > Build and Release > Builds para configurar as definições de Build:

build

Todas as opções abaixo estão disponíveis para configuração:

  • Tasks – Build Name / Agent Queue / Path to solution / Artifact Name
  • Variables
  • Triggers – Continuous Integration (Build every change to matching branches: Disabled) | Gated Check-in (Accept check-ins only if the submitted changes merge and build successfully: Enabled) | Scheduled (Build matching branches for each schedule: Disabled)
  • Options – Build properties (Description / Build number format) / New build request processing: Enable / Automatically link new work in this build… / Create work item on failure / Allow scripts to access OAuth token / Build job / Define build job authorization and timeout settings / Build job authorization scope / Build job timeout in minutes / Build job cancel timeout in minutes / Demands / Specify which capabilities the agent must have to run this process
  • Retetion – Days to Keep / Minimum keep / When cleaning up builds… / History


Release
Também no VSTS > Build and Release > Release para criar as definições de Release:

release

E assim será criado o Pipeline para publicação dos binários, com a escolha do Template, nome do ambiente (que será realizado deploy) e owners do ambiente.

Artefatos de Build
Também podemos criar artefatos de Build, selecionando o Build (na Source Type) que será promovido na Pipeline de Release. Escolha também o projeto e a última versão desenvolvida.

artefato

Há outras configurações como tarefas, variáveis e opções que estão disponíveis no VSTS. Como o propósito foi introduzir o tema, sugiro acessar o Docs da Microsoft para ter mais detalhes sobre as configurações de Build e Release.

 

Eventos DevOps 2018 – Trilhas, Confs e Webinars

Veja abaixo os principais eventos para DevOps e ALM (Application Lifecycle Management) em 2018. Além dos eventos no Brasil, tenha a oportunidade de conhecer alguns eventos internacionais e conferências para você conectar.

Janeiro

Fevereiro

Março

Abril

Maio

Junho

Julho

Setembro

Outubro

Dezembro

 


Data a ser definida…

Recommended Webinars…

ALM (Application Lifecycle Management) – Ciclo de vida da aplicação

1 Comment

Objetivo: abordar os conceitos iniciais do ciclo de vida de uma aplicação
Público: times de desenvolvimento, gestores, analistas, arquitetos, stakeholders e interessados em melhorar o processo de desenvolvimento de sua empresa

No contexto empresarial (grandes, médias, pequenas empresas, startups, etc.) do IT Systems Development, considerando a dificuldade de construir aplicações com a qualidade e valor desejados pelo usuário, o ALM pode ser então definido como o processo que guia a vida útil de uma aplicação desde a sua concepção, passando pela construção, operação e manutenção evolutiva.

alm-001

Diferença entre SDLC x ALM

  • SDLC (Software Development Lifecycle Management) inclui os processos relacionados ao DESENVOLVIMENTO da aplicação como requisitos, arquitetura, codificação, testes e gestão da configuração/projeto.
  • ALM (Application Lifecycle Management) inclui todo o ciclo de vida da APLICAÇÃO, desde a business idea, identificação da necessidade, riscos e desafios. Este ciclo geralmente é encerrado quando a aplicação não é mais utilizada pelo business, potencialmente alguns anos após o desenvolvimento inicial.

 

Pilares ALM

Os pilares que estruturam o ALM e trabalham de forma complementar para prover o gerenciamento do ciclo de vida aplicação:

alm-002

  • Pessoas – o time envolvido na gestão do ciclo de vida da aplicação inclui atribuições desde o alinhamento estratégico até a execução do desenvolvimento de sistemas. As empresas comumente concentram estas responsabilidades em: Executivo, PMO, Gerente de Projetos e Gerente de Operações; Analista de negócios, Arquiteto, Desenvolvedor, Tester e DBA
  • Processos – conjunto de boas práticas, artefatos, guias e manuais que orientam o desenvolvimento e manutenção de uma aplicação
  • Ferramentas – engloba meios/equipamentos/tecnologias que automatizam e facilitam a condução dos processos pelas pessoas

 

Fases do ALM

As fases do ciclo de vida da aplicação podem ser melhor organizadas da seguinte forma:

alm-003

  • Definição: em torno das necessidades e motivações organizacionais. Em método ágeis, por exemplo, a constante validação de produto mínimo viável ou até a identificação de novos mercados.
    • Iniciar: alocar os recursos iniciais – pessoas, processos e ferramentas
    • Definir: converge a ideia em estratégias para desenvolver novas aplicações, considerando os métodos e ferramentas
    • Escolher: a escolha das ferramentas, métodos e tecnologias adequadas para a aplicação é obtida com técnicas como ROI (retorno de investimento), aplicabilidade ao ambiente, etc.
  • Construção: mão na massa (hands on). É a execução do plano definido nas fases anteriores. Independente de um método específico para gerenciar – ágil, waterfall, etc. A restrição tripla (escopo/custo/tempo) além da qualidade deve ser considerada durante a execução. Lembre-se que código ruim não sobe para produção.
  • Operação: após o release da aplicação, precisamos manter o funcionamento adequado da aplicação neste ambiente. Os aspectos de infraestrutura, gestão dos chamados, monitoramento, suporte de fornecedores, entre outros são os assets desta fase. O framework do ITIL é um bom guia para apoiar na gestão dos serviços e atendimento a operação da empresa. O Kanban também é outra forma de trabalhar com operações na sua empresa.
  • Fim: fase final da aplicação, em que a empresa pode evoluir a aplicação com incrementos (adição de novas features) ou substituir a versão.

 

Disciplinas ALM

O uso de disciplinas permite endereçar as entradas e resultados esperados em cada etapa do ciclo de vida da aplicação.

alm-004
Arquitetura e Design
Diretrizes importantes para aplicação (e cumprimento) de práticas e processos entre os times de desenvolvimento. A Arquitetura deve ser disseminada e ter consistência no âmbito de construção da aplicação.

Gerenciamento de Requisitos
Manter a rastreabilidade dos requisitos (comportamento esperado da aplicação) ao longo do ALM. Documentar, priorizar, identificar dependência, conformidade são algumas das ações.

Gestão de Configuração de Software
O processo de construir a aplicação envolve diversos artefatos (código-fonte, documentos, etc.) que devem ter rastreabilidade, controle de acesso, versionamento, entre outros para garantir versões adequadas ao time.

Governança
Esta disciplina mantém a sinergia entre os projetos e processos da empresa, com métricas claras de retorno dos projetos, utilizando ferramentas integradas para gestão de Portfólio.

Implantação e Operações
Além das questões de infraestrutura (ambiente segregados, definição de procedimentos, etc.), a gestão operacional deve ter um controle dos atendimentos (incidentes, defeitos, solicitações, etc.) e monitoramento contínuo, prevendo erros e otimizando o custo de manutenção das empresas.

Testes e QA
Processo de testes para validações como o Teste Unitário (checa o resultado esperado mediante valores de entrada), Teste Integrado (entre módulos), Teste de Regressão (verifica a cada novo Build se não foram gerados Bugs) e métricas de qualidade para validar o processo de homologação junto ao usuário.

Gestão de Projetos
Uma boa gestão dos projetos visa a integração dos processos de desenvolvimento – tarefas, defeitos, mudanças RDMs, etc. – e a estratégia da empresa, apoiando a avaliação financeira e na criação de métricas que justifiquem a execução do Portfolio organizacional. Na prática a integração entre ferramentas de gestão e desenvolvimento como EPM e ALM.

Desenvolvimento
O time de desenvolvimento deve seguir um padrão de codificação com o apoio de arquiteto e líder técnico. O BDD, TDD e DDD são práticas que auxiliam o time técnico a construir e determinar boas práticas para as aplicações. Além de utilização de componentes e recursos de forma adequada.

 

Referências

– Microsoft Technet Library
– Microsoft MSDN
– Microsoft Technet Wiki
– Microsoft Technet Blogs
– Microsoft MSDN Blogs
– https://msdn.microsoft.com/pt-br/library/ee156630.aspx
– https://social.technet.microsoft.com/wiki/pt-br/contents/articles/22899.aspx