Tag: ALM

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 – 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 – Gerenciamento de código-fonte

5 Comments

Objetivo: criar um processo de gerenciamento de código-fonte eficiente para implantação de Continuous Integration na sua equipe de Desenvolvimento.

Benefícios: garantir versões corretas em produção; confiabilidade no rastreamento das mudanças; manter a esteira de implementação veloz e saudável; premissa para utilização de práticas DevOps

O time-to-market, mencionado em métodos ágeis, e considerado em empresas que precisam ter dinâmica e fluidez na criação e lançamento de produtos em produção, necessita de um processo de Integração Contínua para viabilizar frequentes ajustes e garantir entregas rápidas pela equipe de desenvolvimento. É neste contexto que um bom gerenciamento de fontes viabiliza o acesso aos fontes dos pacotes (Version, Service Pack e Hotfix) publicados em produção.

Uma boa prática deste modelo é trabalhar com três linhas:

  • Main: última versão funcional em desenvolvimento – o Configuration Manager realiza alterações via Merge e Check-in
  • Dev: branchs liberadas para desenvolvimento – novas implementações, hotfix e service pack
  • Release: representa os códigos-fonte liberados para produção; criadas a partir do Label aprovado pelo processo de validação de negócio

gestao-fontes

E então o fluxo trabalha com a MAIN para gerenciar o produto – deve estar isolada da linha de DEV e RELEASE. Em novas implementações, deve-se criar uma branch de DEV a partir da MAIN. Para correções, deve ser criada uma branch de HOTFIX, a partir da branch RELEASE correspondente.

Todos os commits de desenvolvimento devem ser realizados na DEV ou HOTFIX. A RELEASE será utilizada como referência ao ambiente de produção. As correções devem ser executadas pelo Configuration Manager via merge: HOTFIX -> RELEASE -> MAIN. Os desenvolvedores ficam encarregados de realizar o merge da MAIN para DEV.

O TFVC (.Net) e GitHub (Java,PHP, etc.) são versionadores utilizados neste contexto.

 

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