00872015 concretesolutions Blog Integracdo e Deployment Continuos como motor de Métodos Ageis hiago Lioy 7022014 Metodologias O que IC/DC tem a ver com Agile? Se considerarmos como fundamentos das metodologias dgeis os 3 pilares transparéncia, inspecao e adaptacdo, as praticas de engenharia mencionadas (IC/DC) fornecem as ferramentas necessarias para aumentar a transparéncia e a nossa capacidade de inspe¢do. Além disso, ajuda a reduzir 0 tempo de cada ciclo de entrega, aumentando a oportunidade do time de se adaptar mais rapidamente (terceiro pilar). De uma maneira geral, essas praticas tendem a aumentar a qualidade do desenvolvimento do projeto, tornando-o mais apto a atender as demandas que vio ao longo de sua vida util . Portanto, sem precisar entrar em detalhes, ja conseguimos observar que Irtograga e deployment cortinuo em metadoa ages | Blog da Conerate uscar Search this website. Newsletter da CS nzenal da Subscribe Categorias: Cloud Com Desenvolvimento (156) Devops (4) E-Commerce (2) Empreendedorismo e Negécios (123) Institucional (40) Mobile (94) ux (6) tiptog.concretesclusens com bx 2014Dinter ac 20-¢ deployment. cortinuns-como-motr-de-melodos- ages) am0082015 Irtograga e deployment corto em metados ages | Blog a Coneete IC/DC tém tudo a ver com a cultura agil IC - Integragao Continua Integragao continua é uma pratica de engenharia de software que teve origem no XP (Extreme Programming) e resume-se a integrar partes distintas do cédigo na maior frequéncia possivel, ou seja, continuamente. 0 problema que ela se propée a resolver é comumente conhecido como “integration hell’, quando diversas partes do cédigo e/ou projeto funcionam separadamente, mas juntas se tornam incompreensivei: forma independente, por si s6, ndo gera valor. Para esse valor ser gerado as partes precisam ser integradas. Em algumas metodologias tradicionais . E pior: Cada parte que funciona de (waterfall, por exemplo) era comum planejar uma fase de integragao no final do projeto, na qual as pecas do quebra-cabeca eram encaixadas e tudo deveria funcionar como planejado meses ou anos antes. Obviamente, hoje sabemos que essa abordagem era furada e na esmagadora maioria das vezes nao dava certo. Se pararmos para pensar, isso era de se esperar. Grandes problemas surgem ao integrar partes distintas do sistema, intensificados pela dificuldade ainda maior de prever que tipo de problemas a tiptog.concretesclusens com bx 2014Dinter ac 20-¢ deployment. cortinuns-como-motr-de-melodos- ages) amtsn1es2015 grag edeloymert carn om metodo | log a Conrete interacao destas distintas e, até ent&o, separadas partes, podem trazer para o projeto. Integracao Continua é 0 inverso disso: garantimos que as pecas do quebra-cabega sejam encaixadas assim que estejam “prontas” e tenham sido enviadas ao repositério de pecas. Essa abordagem diminui o risco, trazendo muitas questdes fundamentais para o presente e garantindo que problemas de integraco sejam resolvidos o mais rapido possivel. Além disso, como essa integracao é feita o tempo todo e com pedacos menores de cédigo, é menos propensa a erros, garantindo que o valor do projeto seja preservado. Sabemos 0 tempo todo que todas as pegas funcionam juntas. Deixando a histéria de lado, na internet existe diversos textos que explicam com muito mais detalhes ¢ aprofundamento o que € e porque fazer IC, como este artigo do Martin Fowler, por exemplo. Na pratica, o que precisamos ter em mente ao falarmos de IC so alguns passos simples, que serdo atendidos por nosso servidor de Integracao Continua: ~ Nosso cédigo ser integrado a cada push (ou de tempos em tempos). Ou seja, toda vez que as mudangas no cédigo forem sincronizadas com 0 repositério, o servidor de IC vai fazer o pull do mesmo € o build do projeto. tiptog.concretesclusens com bx 2014Dinter ac 20-¢ deployment. cortinuns-como-motr-de-melodos- ages)20082015, Irtograga e deployment corto em metadoa des | Blog da Coneete = Testes automatizados rodarao apés 0 build do nosso projeto para garantir que bugs ja encontrados nao voltem e os cenarios de testes continuem a funcionar. Apés cada mudanga no cédigo: — Emails sero enviados para os responsaveis caso 0 build seja quebrado ou os testes nao passem, para que eventuais problemas possam ser corrigidos 0 mais rapido possivel. — Um artefato (entregavel do projeto) sera gerado ao final de um build de sucesso, build + testes pasando. ~ Relatérios serao publicados (so um plus, ndo séo necessarios, mas agregam valor ao Cl) DC - Deployment Continuo Deployment Continuo é outra pratica de engenharia de software, que comega onde IC termina, Apés realizar os passos do IC (baixar o cédigo, integrar, build, rodar os testes e gerar o artefato), faz sentido se questionar sobre o préximo passo. So, what's the next step? A resposta simples & “deployar” esse artefato em algum lugar em que ele possa ser visto ou usado de uma maneira igual ou tiptog.concretesclusens com bx 2014Dinter ac 20-¢ deployment. cortinuns-como-motr-de-melodos- ages) ansn1es2015 grag deployment carn om métoos di | log da Conereto préxima com a qual ele sera usado em produsao. Vamos ilustrar melhor a ideia 1 - Imagine que vocé esté desenvolvendo uma API (Application Programming Interface) e, apés 0 push de uma nova funcionalidade, vocé queira vé-la em QWproducao. Em uma abordagem tradicional, o seu trabalho sé comecou apés o push para o repositério. Agora vocé precisa “buildar” e “deployar” manualmente para seu ambiente de QA. E um trabalho chato, repetitivo, propenso a erro e que definitivamente nao deveria ser feito mais de uma vez. E exatamente aqui que podemos perceber o valor do Deployment Continuo trabalhando junto com a Integracao Continua. Apés adotar essas praticas, seu trabalho se resume a “pushear" cédigo para repositério e a sua Deployment Pipeline se encarregara de “buildar’, rodar os testes, gerar 0 artefato e “deployar” o mesmo no ambiente esperado. 2- Imagine que vocé esté desenvolvendo uma app \0S/Android. Apés terminar uma nova feature, vocé esté querendo mostra-la para os stakeholders . O que muitas vezes acontece é que vocé acaba ficando refém de passar o app para os respectivos celulares através, de cabo USB e coisas do tipo (muito mais facil certo? wrong), tornando seu processo de “deploy” um processo 1-1, que é péssimo, cansativo e trabalhoso. Imagine que vocé precise passar para 5 celulares pelo USB, Tudo bem, certo? 10 minutos, no big deal. Agora considere que sejam 100 e que vocé faca dois releases por dia. J fiquei cansado sé de pensar no trabalho tiptog.concretesclusens com bx 2014Dinter ac 20-¢ deployment. cortinuns-como-motr-de-melodos- ages) on0082015 Irtogragaa e deployment cortino em meados ages | Blog da Coneete Deve existir algum jeito melhor, nao? Sim, existe. ‘Como no exemplo anterior, usar Deployment Continuo faz todo o sentido nesse cenario. Pense que o seu trabalho, apés adotar a pratica, serd “pushear” o cédigo para 0 reposit6rio. Depois disso o Deployment Pipeline se encarregara de “buildar’, testar, gerar seu apk/ipa , gerar uma url e mandar um email para os stakeholders, que poderdo baixar a app com 1 clique. Sounds much better, right? Processo de deploy 1-n Exemplos nao faltam. E antes que vocé pense "tudo bem, muito legal, mas nao funcionaria no meu sistema ou No meu projeto", veja esse post do Steve Blank que conta a histéria da Tesla, fabricante de carros elétricos americana que faz Deployment Continuo em carros. Se eles conseguiram fazer isso com carros, acredite: vocé também pode adotar essa pratica. Sim, existem desafios relacionados a como fazer deployment continuo mas eles ndo sao técnico mas sim de como gerenciar a expectativa do cliente em relacao a mudancas no produto. Experiéncia Aqui na Concrete Solutions ja faz tempo que nos preocupamos em montar o Deployment Pipeline e adotar estas praticas de engenharia de software nos tiptog.concretesclusens com bx 2014Dinter ac 20-¢ deployment. cortinuns-como-motr-de-melodos- ages) onsn1es2015 grag edeloymert carn om metodo | log a Conrete projetos que temos feito, desde os primeiros passos do desenvolvimento. Apés diversos projetos, eu nao poderia ter outra palavra para descrever o resultado se no “sucesso”. © aumento da transparéncia diminui aansiedade dos stakeholders e normalmente faz com que todos os envolvidos participem mais ativamente do projeto. Fora que, para o time que adota essas praticas, o desenvolvimento fica muito mais leve e tranquilo, pois tarefas chatas e repetitivas so automatizadas. Scrum por si 6, ou qualquer metodologia agil, representa um avango, mas com o tempo a adogaio dessas outras praticas de engenharia darao sustentagdo a qualquer mudanca, com aumento da produtividade e da qualidade do projeto como um todo, nas mais diversas esferas. Consideragées finais Por ultimo, quero deixar claro que essas praticas por si 6 nao sao garantia de qualidade no cédigo e, consequentemente, melhoria do seu produto final. De nada adianta usar integraao continua se vocé nao tiver testes automatizados, para destacar um exemplo. Essas praticas geram real valor quando combinadas com outras tantas de engenharia de software, muitas originadas do XP (Extreme Programming), tais como pair programming, code review, refactoring, entre outras, Agile é mais uma mudanga cultural do que qualquer outra coisa e seu maior beneficio esté af. tiptog.concretesclusens com bx 2014Dinter ac 20-¢ deployment. cortinuns-como-motr-de-melodos- ages) ™0082015 Irtograga e deployment corto em metados ages | Blog a Coneete Aideia é que as praticas e a cultura criem ao redor do time/empresa uma “safety net” que favoreca 0 aprendizado, a melhoria continua (kaizen) e 0 desenvolvimento pessoal. Cultura corporativa é um t6pico extenso com muitos exemplos para estudarmos (Google, Facebook, etc). Para fechar, vou deixar esse link de um livro que fala como a Toyota desenvolveu uma cultura corporativa invejada ao redor do mundo, cultura essa que deu origem ao lean, grande influéncia para as metodologias ageis. Tem alguma duvida? Gostaria de acrescentar alguma coisa? Comente! PS: Estou publicando uma série de posts sobre integragao continua em iOS. Se vocé ainda nao viu, pode aprender com a parte 1 neste link e a parte 2 neste aqui. Confira Também 1, As barreiras e a importancia da adogao de métodos dgeis 2. Como desenvolver app iOS com TDD, cobertura e Integracao Continua - Parte 1 3. Como desenvolver app iOS com TDD, cobertura e Integracao Continua - Parte 2 4, Ponderacées de um veterano sobre praticas tiptog.concretesclusens com bx 2014Dinter ac 20-¢ deployment. cortinuns-como-motr-de-melodos- ages)0082015 Irtograga e deployment corto em metados ages | Blog a Coneete ageis agile) [> deployment continuo _* integrago continua 7 métodos ageis Did you like this article? Share it with your friends! Like {2 ] Twoot (6| 3+ 0 Written by Thiago Lioy Consultor especialista da Concrete Solutions, com grande experiéncia em mobile, desde apps nativas até hibridas e seus respectivos back- ends. Desenvolvedor iOS/Android & Ruby por hobby. Defensor de métodos ageis e Lean Thinking, acredita que so uma maneira de sintetizar um processo com passos bem definidos para trazer de volta © bom senso para a industria de software. Comments — Community @ Login @ Recommend Sort by Best Join the discussior Geovani dos Santos - t la Thiago, parabéns pela matéria, obrigado por compartihar este aprendizado. Gostaria de saber sobre como ¢ geralmente a aceitagao € curva de aprendizagem dos times. © que os tiptog.concretesclusens com bx 2014Dinter ac 20-¢ deployment. cortinuns-como-motr-de-melodos- ages) on0082015 ier 2pa0 © detent continu em metode eis | log da Concrete desenvolvedores precisam buscar saber para cooperarem com esta pratica? Quais s4o as possiveis desvantagens desta pratica de IC/DC? Penso em implantar IC/DC para desenvolver app Android, usando Jenkins em um Servidor IC virtual no Windows Azure, mais outros dois, um Servidor Git e um Servidor DC, Penso que esta pratica nao exige aprendizagem de todo 0 time, apenas de quem ira implantar, o responsavel pelo QA, para configurar e decidir 0 melhor processo de IC/DC do nosso caso, quanto aos demais desenvolvedores, apenas aprender a implementar os testes automaticos para agregar na qualidade. 4 + Reply + St € Thiago Lioy ->Ceovari dos Sar + Smonthe 2 CVCD ajuda muito a aumentar a transparéncia do projeto, gerando mais feedback, por exemplo Porém, outras vantagens notaveis s4o diretamente relacionadas ao time. Processos de build, release, deploys, testes, entre outros, que possuem como elo serem tarefas “trabalhosas”, repetitivas e tediosas, so substituidas por builds automatizados que vocé escreve uma vez e nao precisa mais ficar se preocupando em ter que “starta-los” manuaimente. Destacar esses pontos para o time de desenvolvimento praticamente garante o buyin deles quanto a adogo das praticas, pois os mesmos vao ver valor nelas Na verdade, o valor da pratica existe quando ela é “comprada" de verdade por todos os envolvidos no projeto. Parte fundamental é conseguir demonstrar para o time os valores que ela agrega no processo, ao invés do time ter uma percepgao de que é algo sendo empurrado top-down. A discussao precisa ser muito mais na linha de: “olha como nos faziamos isso antes x como fazemos agora, quanto tempo e desperdicio foram eliminados do proceso” "Penso que esta pratica nao exige aprendizagem de todo 0 time" => 0 problema dessa visao € que a CICD vai ser visto belas demais como atribuicdo e -iptog.concretesclusens com br/20142inte ac 20-¢ deployment cortinuns-cemo-molr-de-melodos- ages son0082015 Irtograga e deployment corto em meds ages | Blog da Coneete tarefa de uma pessoa especifica e isso tem consequéncias ruins, pois quando o “Senhor Integragdo Continua” nao estiver presente (férias, doenga, etc.), 0 processo vai desandar. CICD € muito mais uma mudanga comportamental na forma de se desenvolver software do que uma ferramenta ou outra especifica, é quase como se fosse uma injegao de bom senso no desenvolvimento. Surpreendente ou ndo, quando se explica para as pessoas e mostra-se as vantagens dessa mudanga, dificilmente elas querem voltar como era antes. + Reply + Shar Guest - Smonthse Na verdade, o valor da pratica existe quando ela é “comprada" de verdade por todos os envolvidos no projeto Parte fundamental é conseguir demonstrar para o time os valores que ela agrega no processo, ao invés do time ter uma percepgao de que ¢ algo sendo empurrado top-down, A discusso precisa ser muito mais na linha de: “olha como nos faziamos isso antes x como fazemos agora, quanto tempo e desperdicio foram eliminados do proceso” CIICD ajuda muito a aumentar a transparéncia do projeto, gerando mais feedback, por exemplo, Porém, outras vantagens notaveis sao diretamente relacionadas ao time. Processos de build, release, deploys, testes, entre outros, que possuem como elo serem tarefas “trabalhosas”, repetitivas e tediosas, sdo substituidas por builds automatizados que vocé escreve uma vez endo precisa © 2015 Blog da Concrete Powered by Pinboard Theme by One Designs and WordPress tiptog.concretesclusens com bx 2014Dinter ac 20-¢ deployment. cortinuns-como-motr-de-melodos- ages) nn