• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Desenvolvimento e manutenção de software usando práticas do gerenciamento do ciclo de vida da aplicação e desenvolvedor/operação
 

Desenvolvimento e manutenção de software usando práticas do gerenciamento do ciclo de vida da aplicação e desenvolvedor/operação

on

  • 168 views

Neste artigo o leitor será apresentado ao mundo do desenvolvimento e manutenção ...

Neste artigo o leitor será apresentado ao mundo do desenvolvimento e manutenção
de software envolvendo técnicas e práticas do Gerenciamento do Ciclo de Vida da
Aplicação ALM da sigla em inglês para Application Lifecycle Management e a cultura
Desenvolvedor/Operação (DevOps), será abordado um breve histórico de como
surgiu essas práticas, o que se deseja alcançar com a implantação, os principais
pilares de cada técnica e como implantar essas técnicas e práticas em uma fábrica
de software. Ao final deste artigo o leitor terá o conhecimento para iniciar a discursão
em sua organização para a implantação dessas técnicas e práticas com
embasamento.

Statistics

Views

Total Views
168
Views on SlideShare
168
Embed Views
0

Actions

Likes
0
Downloads
0
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    Desenvolvimento e manutenção de software usando práticas do gerenciamento do ciclo de vida da aplicação e desenvolvedor/operação Desenvolvimento e manutenção de software usando práticas do gerenciamento do ciclo de vida da aplicação e desenvolvedor/operação Document Transcript

    • DESENVOLVIMENTO E MANUTENÇÃO DE SOFTWARE USANDO PRÁTICAS DO GERENCIAMENTO DO CICLO DE VIDA DA APLICAÇÃO E DESENVOLVEDOR/OPERAÇÃO Washington Clemente dos Santos Borges1 Orientador: Gustavo Monti Rocha2 RESUMO Neste artigo o leitor será apresentado ao mundo do desenvolvimento e manutenção de software envolvendo técnicas e práticas do Gerenciamento do Ciclo de Vida da Aplicação ALM da sigla em inglês para Application Lifecycle Management e a cultura Desenvolvedor/Operação (DevOps), será abordado um breve histórico de como surgiu essas práticas, o que se deseja alcançar com a implantação, os principais pilares de cada técnica e como implantar essas técnicas e práticas em uma fábrica de software. Ao final deste artigo o leitor terá o conhecimento para iniciar a discursão em sua organização para a implantação dessas técnicas e práticas com embasamento. PALAVRAS-CHAVE: ALM, DevOps, Desenvolvimento e Manutenção de Software. INTRODUÇÃO Segundo Durães (2012) estamos na era do engajamento, da tecnologia. Hoje os consumidores de tecnologia estão cada vez mais exigentes com os produtos que consomem, e se faz necessário que o mercado de software acompanhe essas mudanças. Desta forma, as empresas que desenvolvem softwares tem a missão de alinhar seus processos de desenvolvimento e a operação de tal forma que seja possível entregar software de maneira rápida mantendo a continuidade dos serviços. Washington Clemente dos Santos Borges, concluinte do curso de Pós-Graduação em Engenharia de Software Centrada em Métodos Ágeis, Analista de Sistemas na Maxprocess Consultoria, ton.borges@gmail.com. Gustavo Monti Rocha, Analista de Sistemas no Serviço Federal de Processamento de Dados - SERPRO
    • Sendo assim, existem atualmente algumas disciplinas e técnicas que podemos aplicar para que seja possível atingir esses objetivos. PROBLEMA Atualmente o tamanho dos softwares desenvolvidos tem sido cada vez maior. Há cerca de 30 anos eles eram setoriais, contudo, nos dias de hoje eles controlam toda a operação de uma empresa. Devido a esta mudança, se faz necessário cuidar melhor de toda a cadeia produtiva do software, ou seja, desde como e onde armazenar os códigos fontes à maneira como ele é entregue. JUSTIFICATIVA Neste artigo vamos introduzir o leitor ao mundo do desenvolvimento ágil de software, através do gerenciamento do ciclo de vida da aplicação (ALM) e Operação/Desenvolvimento (DevOps). O leitor irá compreender as técnicas utilizadas por essas disciplinas e verá como é possível unir estas de forma que possa ajudar no processo de desenvolvimento/manutenção de software de forma a atender o mercado de forma mais rápida e dinâmica. DEVOPS HISTÓRIA O termo DevOps foi criado em 2009 na conferência Velocity da O'Reilly com a apresentação do trabalho 10+ Deploys Per Day: Dev and Ops Cooperation at Flickr por John Allspaw e Paul Hammond. Entretanto, Carvalho (2013) relata que em 2008 já se discutia sobre o assunto com o termo “infraestrutura ágil”. Willis (2011) relata que no Agile 2008 surgiram conversas sobre como incorporar a metodologia ágil na infraestrutura, e a lista de discussão agile-sysadmin foi quem iniciou a construção da ponte entre desenvolvedores e administradores de sistemas. Patrick Debois era um dos participantes desta lista e um grande entusiasta do assunto. Após assistir a palestra de John e Paul ele ficou tão animado que criou
    • ainda em 2009 o evento chamado DevOpsDay. Para Carvalho (2013) foi nesse encontro na cidade Ghent – Bélgica no final de 2009 que tudo começou. Esse evento continua acontecendo em várias partes do mundo ano após ano. COMO FUNCIONA A INFRAESTRUTURA E O DESENVOLVIMENTO DE SOFTWARE HOJE Carvalho (2013) faz um relato sobre as atividades desses departamentos hoje em dia: a infraestrutura é responsável pela manutenção dos sistemas sendo ela quem faz todos os deploys e rollbacks. É também responsável por monitorar cada um, verificando disponibilidade, carga em servidores e se preocupar com os SLA (acordo de nível de serviço). Como consequência, o impacto de uma parada na aplicação é grande, podendo gerar grandes prejuízos financeiros. Com esse cenário, Carvalho (2013) afirma que a preocupação da infraestrutura é proteger o valor do negócio. Os desenvolvedores estão constantemente criando e aprimorando suas aplicações, com isto novas versões são criadas e precisam ser disponibilizadas, assim seus clientes poderão usufruir dos recursos solicitados. (CARVALHO, 2013) Nesta citação de Carvalho (2013) é fácil perceber que irá existir um conflito entre desenvolvimento e infraestrutura, pois o desenvolvimento precisa que suas alterações tenham suas builds realizadas de maneira rápida de forma a aumentar do valor do negócio. Nessa cultura, a equipe de operações normalmente é isolada da de desenvolvimento, e as interações entre as duas é evitada ou forçada. A característica marcante desse extremo é que o desenvolvimento e as operações têm objetivos marcadamente contrários. A equipe de desenvolvimento é comprometida e recompensada com entregas de novas funcionalidades e em levar o produto adiante. O objetivo da equipe de operações é manter a estabilidade acima de tudo. Sem a comunicação correta, os objetivos entram em conflito, pois o interesse da equipe de operações é não entregar novas funcionalidades, e o maior interesse do desenvolvimento é entregar novas funcionalidades o mais rápido possível. (HASHIMOTO, 2013),
    • Hashimoto (2013) confirma a visão de Carvalho sobre esse conflito existente hoje entre infraestrutura e desenvolvimento onde cada setor somente se preocupa com os resultados a serem entregues de seus respectivos setores. MUDANÇAS NECESSÁRIAS Carvalho (2013) relata sobre a necessidade da evolução na infraestrutura de forma rápida e que o desenvolvimento precisa ter controle de todas as fases das gerações das builds e deploy. Na infraestrutura isso se dá na parte de automatização de tarefas, ela deve prover meios para que o desenvolvedor consiga fazer deploy de forma automática, sem necessidade de interversão da infraestrutura. Sete (2013) ainda comenta sobre a necessidade do feedback contínuo, seja ele de pessoa ou de máquina, onde infraestrutura e desenvolvimento tenham uma melhor comunicação. CULTURA DEVOPS Carvalho (2013) relata que Patrick Debois diz que DevOps é uma cultura, e que essa seria dividida em 4 partes, a saber: • Cultura o o Fim das divisões o Relação saudável entre as áreas o • Colaboração Mudança de comportamento Automação o Deploy o Controle
    • o o Gerência de configuração o • Monitoração Orquestração Avaliação o o Medições o Performance o • Métricas Logs e integração Compartilhamento o O feedback é tudo o Boa comunicação entre a equipe APPLICATION LIFECYCLE MANAGEMENT (ALM) HISTÓRIA O ALM (Gerenciamento do Ciclo de Vida da Aplicação) surgiu da necessidade de controlar toda a cadeia produtiva do software. Farias (2012) lembra que com o avanço da tecnologia em diversos campos, o software tem ficado cada dia mais complexo e gerando cada vez mais valor aos negócios dos clientes. Essa complexidade a que Farias (2012) se refere vem da necessidade da integração do software com outros softwares, e/ou alteração em softwares críticos que já estão em produção. Farias define todo esse processo de construção de novos softwares e alteração dos que já existem de ALM.
    • PILARES PARA ALM Condé (2009) define que o ALM é estruturado em cima de três pilares que se complementam. São eles: pessoas, processos e ferramentas, que quando unidos fornecem os recursos necessários para que as empresas possam gerenciar todo o ciclo de vida de uma aplicação. • PILAR PESSOAS Pessoas bem treinadas e capacitadas formam a cola que unem adequadamente as ferramentas e os processos do ALM. • PILAR PROCESSOS O pilar “processos” é identificado como todo o conjunto de boas práticas, artefatos, guias e manuais que conduzem a construção e manutenção de uma aplicação. • PILAR FERRAMENTAS Por último, as “ferramentas” são os meios/equipamentos/tecnologias que automatizam e facilitam a condução dos processos pelas pessoas. DISCIPLINAS PRESENTES NO ALM Vamos analisar abaixo todas as disciplinas que Condé (2009) classifica como disciplinas presentes e essenciais ao ALM. GERENCIAMENTO DE REQUISITOS Condé (2009) define o gerenciamento de requisitos como a prática de documentar e manter a rastreabilidade dos requisitos ao longo do ciclo de vida da aplicação. Dentro do gerenciamento de requisitos temos algumas funcionalidades: • Documentar os funcionais e não funcionais; • Identificar se estão aderentes com as necessidades de negócio; • Priorizar os requisitos;
    • • Selecionar os que serão implementados no projeto ou em fase específica; • Identificar a dependência entre os mesmos; • Mapeá-los com a arquitetura; • Mapeá-los com as funcionalidades da aplicação; • Verificar se foram atendidos e estão em conformidade com as necessidades dos usuários. GERENCIAMENTO DA CONFIGURAÇÃO DE SOFTWARE Dantas (2012) define a gerencia de configuração como uma disciplina que controla e notificam as inúmeras correções, extensões e adaptações aplicadas durante o ciclo de vida do software de forma a assegurar um processo de desenvolvimento e evolução sistemático e rastreável, sendo indispensável quando equipes manipulam, muitas vezes em conjunto, artefatos comuns. Condé (2009) ainda define algumas funcionalidades realizadas pela gerencia de configuração, a saber: • Controlar o acesso aos artefatos; • Armazenar as múltiplas versões de cada artefato; • Rastrear as modificações de cada versão; • Comparar versões; • Identificar a versão dos artefatos que estão diretamente ligados a uma versão final da aplicação; • Restaurar versões especificas dos artefatos baseados em uma versão específica da aplicação. MONTAGEM E INTEGRAÇÃO Para Condé (2009) A disciplina de Montagem e Integração consiste na prática de unir todos estes componentes em apenas um único pacote, a fim de ser testado e distribuído na infraestrutura de TI. Algumas das funcionalidades da disciplina são: • Recuperar todos os artefatos do repositório de código-fonte; • Mapear os artefatos com a nova versão da aplicação;
    • • Compilar o código-fonte; • Organizar o código compilado em um específico layout conforme definido; • Criar um pacote de instalação (setup) para ser testado; • Abortar o processo de build caso encontre algum erro ou inconsistência nos artefatos. ENGENHARIA E DISTRIBUIÇÃO Para Condé (2009) a disciplina de Engenharia de Distribuição é responsável por garantir a consistência das diversas versões da aplicação: • Documentação das dependências externas de cada versão; • Minimizar o tempo entre as atualizações de versões; • Utilização de ferramentas para automatizar a distribuição das versões ou correções; • Tratar rapidamente as falhas de distribuição. GERENCIAMENTO DE DEFEITOS Quintela e Araújo (2012) definem que a gerência de defeitos tem como objetivo definir práticas para prevenir os defeitos e minimizar os riscos de um projeto. Condé (2009) define algumas ações da disciplina de Gerenciamento de Defeitos: • Descrever o comportamento esperado; • Descrever o comportamento ocorrido; • Descrever os passos necessários para reproduzir o defeito; • Priorizar os defeitos conforme a demanda; • Direcionar o defeito para ser corrigido por um desenvolvedor; • Registrar se o defeito foi corrigido.
    • TESTE UNITÁRIO, INTEGRADO E DE REGRESSÃO O teste unitário é o teste isolado e exercido apenas sobre um componente, que pode ser uma classe ou um método. Os testes integrados atuam sobre módulos, é uma tarefa normalmente executada pelos programadores. Os testes de regressão verificam se as alterações introduzidas a cada novo build não geraram novos defeitos. O benefício de aplicar estes testes é o de garantir a qualidade do software e sua conformidade com os requisitos definidos. Algumas ações: • Criação de testes unitários para cada componente; • Criação dos testes integrados no nível de módulos lógicos e casos de uso; • Os testes são também considerados artefatos, e assim devem ser armazenados dentro do repositório; • Uso de ferramentas para automatizar a geração de relatórios e logs de erros. ANALISE DE CÓDIGO A disciplina Análise de Código é responsável em identificar se o código escrito está aderente a padrões e políticas da empresa. Algumas ações realizadas por esta disciplina: • Validar o formato e estilo de codificação; • Verificar a documentação interna do código; • Garantir o uso de “design patterns”; • Detectar problemas de desempenho; • Identificar vulnerabilidades conforme as políticas de segurança; • Garantir a proteção e privacidade das informações que a aplicação manipula; • Identificar a compatibilidade da aplicação em conformidade com normas de mercado.
    • TESTE DE SISTEMA Condé (2009) afirma que a disciplina Teste de Sistema envolve o teste da aplicação quando completada. Os testes funcionais, conhecidos como testes “de caixa preta”, são executados por esta disciplina. Eles procuram identificar se a aplicação está aderente aos requisitos, além de serem usados como ferramentas para aceitação ou não da aplicação construída. Os testes de sistema são facilitados quando as disciplinas de gerenciamento de requisitos, configuração de software, análise de código e gerenciamento de defeitos são executadas corretamente. Algumas ações típicas desta disciplina: • Detectar problemas em desempenho; • Detectar se os requisitos estão presentes na aplicação. METODOLOGIA Criar um roteiro de implantação do ALM e DevOps para uma fábrica de software de Belo Horizonte, Minas Gerais, que trabalha com tecnologia Microsoft e Eclipse com o SDK Android. Atualmente na empresa já existe uma instalação do Team Foundation Server (TFS) na versão 2012 que é usado como controle de versão, sem nenhum benefício adicional. Para o rastreamento de defeitos e lançamentos de tarefas, hoje é usado o Redmine, que posteriormente será substituído pelo TFS usando a estrutura de itens de trabalho. Abaixo serão descritos 7 passos para a implantação deste roteiro, considerando a realização de apenas um passo por mês. Passo 1: Configuração do Controle de Versão: Será configurado para cada projeto específico, branchings, garantindo assim, que sempre exista um branching para Produção, Homologação e Desenvolvimento. Cada projeto especifico receberá suas
    • configurações de segurança, ou seja, somente membros da equipe do projeto poderão ter acesso aos arquivos, podendo também controlar quais arquivos terão check outs exclusivos evitando que seja necessário realizar merge em arquivos com alto grau de complexidade para essa operação. Passo 2: Configuração dos Itens de Trabalho: Nesta etapa serão lançadas todas as tarefas, sejam de defeitos, implementação ou até mesmo de testes. Com o item de trabalho configurado e sendo usado da maneira correta, será possível criar a rastreabilidade do código, pois ao fazer o check in de alguma alteração no código, será necessário informar a qual item de trabalho pertence determinada alteração mantendo principalmente a rastreabilidade entre os mesmos. Serão configurados alguns relatórios e gráficos, para que se possa saber: os itens de trabalho pendentes de implementação, quantos são de erros, acompanhamento em tempo real do andamento dos itens de trabalho, product backlog concluído e outros. Passo 3: Testes unitários: Serão realizados workshops sobre como implementar de forma correta testes unitários, quando e onde aplicar para que com isso a qualidade dos códigos sejam melhorada. Passo 4: Ainda referente a testes, será implementado o teste funcional, usando o Test Manager do Visual Studio. Com ele é possível trabalhar com o conceito de defeitos ricos, pois isso acaba com o dilema de que isso "funciona na minha máquina”. O Test Manager coleta dados da aplicação enquanto realiza os testes, inclusive criando um IntelliTrace, que é a pilha de execução da aplicação que em casos de erros o desenvolvedor pode ver o que estava na memória no momento do erro. Passo 5: Configuração do Lab Manager: Esse passo terá um grande envolvimento da equipe de Infraestrutura, onde será criada uma biblioteca de máquinas virtuais, para que os testadores possam ter ambientes distintos para testes.
    • O Lab Manager é um gerenciador de ambientes virtuais, que estende o TFS, onde os testadores de software podem criar e gerenciar seus ambientes, conforme a necessidade de cada software a ser testado. Com o Lab Manager a cada erro encontrado o testador pode realizar um snapshot da máquina virtual e enviar para o desenvolvedor que irá receber a máquina no estado que ocorreu o erro. Passo 6: Configuração de Testes de Interface: Até o momento já temos alguns processos de testes implantados, agora deve-se aprimorar essas técnicas usando o Coded UI Test. Com o Coded UI Test é possível gravar uma macro com os itens a serem testados na interface do aplicativo, com isso, é gerado o código de teste onde o Visual Studio é capaz de executar. Passo 7: Configuração do Team Build: O build da aplicação será realizado de forma automatizada, ou seja, a cada build que o TFS realizar será executada toda a bateria de testes, sejam eles unitários ou funcionais. Ainda neste passo será configurado o deploy continuo em ambiente de homologação. A cada build realizado com sucesso, todos os itens de trabalhos que pertencem ao build gerado serão integrados no branching de homologação e será realizado o deploy no servidor de homologação. CONCLUSÃO A implantação do ALM e DevOps, causa uma mudança de cultura muito grande na empresa. Ela deve sempre ser realizada de forma que minimize os impactos para a equipe de forma que não atrapalhe o andamento dos projetos e que todos os envolvidos se sintam confortáveis com essa mudança. Ela deve ser realizada e pensada à longo prazo, pois os resultados serão percebidos conforme o avanço de cada etapa. É importante ressaltar que, a implantação irá variar de empresa para empresa conforme a demanda e/ou necessidade de cada uma. Sendo assim, é necessário
    • realizar uma análise do ambiente. Nem todas as políticas do ALM precisam ser implantadas. Deve-se realizar uma análise empresarial para identificar os pontos de carência e onde as práticas do ALM agregam maior valor. Devido ao prazo estimado para implantação completa deste trabalho (em torno de 7 meses), não será possível apresentar neste artigo os resultados obtidos com a implantação aqui proposta. REFERÊNCIAS CARVALHO, J. A. 2013. Disponível em: <http://gutocarvalho.net/octopress/2013/03/ 16/o-que-e-um-devops-afinal/> Acesso em: 10/10/2013 HASHIMOTO, M. 2013. Disponível em: <http://www.infoq.com/br/articles/wide-rangedevops> Acesso em: 13/10/2013 DURÃES, R. Disponível em: <http://www.microsoftvirtualacademy.com/Content/ ViewContent.aspx?et=2170&m=2166&ct=14599#?fbid=zloEhVZMcNU> Acesso em: 01/10/2013 SETE, M. 2013. Palestra ALM Pratices. FARIAS, W. 2012. Disponível em: <https://www.ibm.com/developerworks/ community/blogs/rationalbrasil/entry/alm?lang=en> Acesso em: 16/11/2013 CONDÉ, L. 2009. Disponível em: <http://msdn.microsoft.com/pt-br/ library/ee156630.aspx#item2> Acesso em: 15/11/2013. DANTAS, C. 2012. Disponível em: <http://www.devmedia.com.br/gerencia-deconfiguracao-de-software/9145#ixzz2kscbTc5z> Acesso em: 16/11/2013 QUINTELA, B 2012 E ARAÚJO, M. 2012. Engenharia de Software Magazine Edição 47. WILLIS, J 2011. Disponível em: http://itrevolution.com/the-convergence-of-devops/ Acesso em: 16/11/2013.
    • TRABALHO DE CONCLUSÃO DE CURSO PÓS-GRADUAÇÃO LATO SENSU Aluno (a): Washington Clemente dos Santos Borges Curso: Turma: Engenharia de Software Centrada em Métodos Ágeis 2013/4 Título do Artigo: DESENVOLVIMENTO E MANUTENÇÃO DE SOFTWARE USANDO PRÁTICAS DO GERENCIAMENTO DO CICLO DE VIDA DA APLICAÇÃO E DESENVOLVEDOR/OPERAÇÃO Professor Orientador: Gustavo Monti Rocha Coordenador do curso: Yoris Linhares Data: 16 de Dezembro de 2013 Resumo: Neste artigo o leitor será apresentado ao mundo do desenvolvimento e manutenção de software envolvendo técnicas e práticas do Gerenciamento do Ciclo de Vida da Aplicação ALM da sigla em inglês para Application Lifecycle Management e a cultura Desenvolvedor/Operação (DevOps), será abordado um breve histórico de como surgiu essas práticas, o que se deseja alcançar com a implantação, os principais pilares de cada técnica e como implantar essas técnicas e práticas em uma fábrica de software. Ao final deste artigo o leitor terá o conhecimento para iniciar a discursão em sua organização para a implantação dessas técnicas e práticas com embasamento. Total de pontos: Situação Final: ( )Aprovado ( )Reprovado ________________________ ________________________ Professor Orientador Coordenador
    • DECLARAÇÃO DE RECEBIMENTO DO TRABALHO DE CONCLUSÃO DE CURSO Declaro, para os devido fins, que recebi a ata de avaliação com dados e resumo do TCCTrabalho de Conclusão de Curso do(a) aluno(a) Washington Clemente dos Santos Borges, da turma 2013/4, do Curso de Pós-Graduação Lato Sensu Engenharia de Software Centrada em Métodos Ágeis, devidamente datada e assinada pelo professor orientador, com indicação de aprovação do aluno no TCC. Declaro ainda ser de minha responsabilidade encaminhar ao NTCC (Núcleo de Trabalho de Conclusão de Curso) o documento citado acima. Belo Horizonte, ___ de _______________ de ______. Nome do Coordenador(a): Yoris Linhares_____________________________ Recebido por:___________________________________________________ Assinatura: _____________________________________________________