{"id":5501,"date":"2022-09-12T17:09:29","date_gmt":"2022-09-12T20:09:29","guid":{"rendered":"https:\/\/elemarjr.com\/engenhariadesoftware\/?p=5501"},"modified":"2022-09-12T17:09:29","modified_gmt":"2022-09-12T20:09:29","slug":"github-flow","status":"publish","type":"post","link":"https:\/\/elemarjr.com\/livros\/engenhariadesoftware\/github-flow\/","title":{"rendered":"Acelerando entregas com o Github Flow"},"content":{"rendered":"
\r\n\r\n\r\n\r\n
\"\"<\/td>\r\n\"\"Este artigo foi escrito em parceria com Douglas Picolotto<\/a> – especialista em Nuvem e DevOps.<\/td>\r\n<\/tr>\r\n<\/tbody>\r\n<\/table>\r\n<\/div>\n

H\u00e1 consenso que frequ\u00eancia de<\/strong> deploy<\/strong><\/em> e delivery lead-time<\/strong><\/em> s\u00e3o duas das m\u00e9tricas mais importantes para determinar a efici\u00eancia, inclusive estrat\u00e9gica, da engenharia de software.<\/p>\n

Nesse cap\u00edtulo, tratamos de um fluxo de trabalho que favorece estas m\u00e9tricas: Github Flow.<\/p>\n

O que \u00e9 o Github Flow<\/em>?<\/h2>\n

Github flow<\/em> \u00e9 uma alternativa notoriamente mais \u00e1gil para o Git flow<\/a>.<\/strong><\/p>\nGit flow<\/em><\/a> \u00e9, certamente, a estrat\u00e9gia de branching<\/em> mais conhecida do mercado. Criado em 2010, popularizou uma abordagem organizada e consistente para entregar software usando git<\/em>. Entretanto,\u00a0 com a evolu\u00e7\u00e3o das pr\u00e1ticas de engenharia de software<\/i>, especialmente continuous deployment<\/i>, tornou-se relativamente burocr\u00e1tico, e pouco eficiente em cen\u00e1rios onde deploys<\/i> podem acontecer todos os dias, pois trabalha em ciclos de release<\/i>.\n

\n

O GitHub Flow<\/em> surgiu como uma op\u00e7\u00e3o mais simples e \u00e1gil de entregar software. Utilizada pelo pr\u00f3prio Github<\/em>, permite que features<\/em> sejam liberadas em produ\u00e7\u00e3o todos os dias, assim que ela for integrada ao branch main<\/em>. Para termos uma ideia, apenas no dia 23 de agosto de 2012, o Github<\/em> chegou a fazer 175 deploys<\/em> em produ\u00e7\u00e3o.<\/strong><\/p>\n

Como funciona o Github Flow<\/em>?<\/h2>\n

O Github Flow<\/em> trabalha basicamente com a branch main<\/em> de longa dura\u00e7\u00e3o e com branches<\/em> de trabalho, onde novas features<\/em> e corre\u00e7\u00f5es s\u00e3o desenvolvidas constantemente.<\/p>\n

\r\n\r\n\r\n\r\n
\"\"<\/td>\r\n\"\" Partindo da premissa de que tudo que est\u00e1 na branch main<\/em> pode ser publicado, o Github Flow<\/em> orienta a efetuar um deploy<\/em> em produ\u00e7\u00e3o, sempre que um novo commit<\/em> for efetuado nesta branch<\/em>.<\/p>\r\n<\/td>\r\n<\/tr>\r\n<\/tbody>\r\n<\/table>\r\n<\/div>\n

Um ponto extremamente importante neste modelo \u00e9 a revis\u00e3o de c\u00f3digo feita atrav\u00e9s de pull requests<\/em>.<\/p>\n

Este fluxo n\u00e3o tem espa\u00e7o para \u201cFriendly Review<\/em>\u201d e, similar \u00e0 uma rede social, permite a discuss\u00e3o sobre determinada altera\u00e7\u00e3o, fornecendo feedback<\/em> para quem desenvolveu, e alinhamento entre todas as partes interessadas, mesmo antes da altera\u00e7\u00e3o estar pronta.<\/p>\n

Devido ao curto ciclo de entrega, \u00e9 imprescind\u00edvel tamb\u00e9m uma boa base de automa\u00e7\u00e3o, com testes automatizados, an\u00e1lise est\u00e1tica de c\u00f3digo e seguran\u00e7a, al\u00e9m da entrega automatizada.<\/p>\n

Github flow\u00a0<\/i>\u00e9 sempre “melhor” que o Git flow?<\/em><\/h2>\n

A pergunta que voc\u00ea deve estar se fazendo \u00e9 \u201cQual o melhor?\u201d. Sem sombra de d\u00favidas, a resposta \u00e9 \u201cdepende\u201d.<\/p>\n

Depende da natureza do software<\/em>, da cultura dos times, da metodologia de desenvolvimento. Se existe a necessidade de efetuar releases fora dos hor\u00e1rios comerciais, ou o time trabalha com um modelo de sprints, Git Flow<\/em> pode fazer mais sentido.<\/p>\n

Em contrapartida, para times que t\u00eam a possibilidade de entregar software com mais frequ\u00eancia, Github Flow<\/em> fornece um fluxo mais simples e \u00e1gil, atrav\u00e9s de pequenas itera\u00e7\u00f5es (commits<\/em> e pull requests<\/em>).<\/strong> Como diz o ditado: \u201c\u00c9 mais f\u00e1cil movimentar pequenas pedras, do que montanhas\u201d.<\/p>\n

M\u00e9tricas! M\u00e9tricas!<\/h2>\n

Apesar de bastante simples, o Github Flow<\/em> permite que tenhamos acesso a algumas m\u00e9tricas importantes para o ciclo de desenvolvimento.<\/p>\n

Nesse fluxo, \u00e9 incrivelmente f\u00e1cil apurar tanto a frequ\u00eancia de deploy<\/strong> quanto o\u00a0deployment lead-time<\/strong>,<\/em>\u00a0pois a cada merge<\/em> na main<\/em>, \u00e9 efetuado um novo deploy<\/em> em produ\u00e7\u00e3o.<\/p>\n

Para Pensar<\/h2>\n

Github flow<\/em> tem sido usado como base de desenvolvimento para o pr\u00f3prio Github<\/em> com sucesso, permitindo dezenas (e at\u00e9 centenas) de deploys<\/em> em um \u00fanico dia.<\/p>\n

Com as pr\u00e1ticas de software adequadas, o Github Flow<\/em> permite que times que trabalham entregando batches<\/em>, mas que tenham condi\u00e7\u00f5es de entregar uma feature<\/em> assim que ela estiver pronta, mudem de estrat\u00e9gia, tornando o ciclo de desenvolvimento fluido e cont\u00ednuo, resultando em maior agilidade para o processo como um todo.<\/p>\n","protected":false},"excerpt":{"rendered":"

H\u00e1 consenso que frequ\u00eancia de deploy e delivery lead-time s\u00e3o duas das m\u00e9tricas mais importantes para determinar a efici\u00eancia, inclusive estrat\u00e9gica, da engenharia de software. Nesse cap\u00edtulo, tratamos de um fluxo de trabalho que favorece estas m\u00e9tricas: Github Flow. O que \u00e9 o Github Flow? Github flow \u00e9 uma alternativa notoriamente mais \u00e1gil para o […]<\/p>\n","protected":false},"author":2,"featured_media":5515,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[],"tags":[],"url":[72],"apendices":[],"capitulos":[38],"class_list":["post-5501","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","url-permanente","capitulos-capitulo-2-2"],"acf":[],"_links":{"self":[{"href":"https:\/\/elemarjr.com\/livros\/engenhariadesoftware\/wp-json\/wp\/v2\/posts\/5501","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/elemarjr.com\/livros\/engenhariadesoftware\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/elemarjr.com\/livros\/engenhariadesoftware\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/elemarjr.com\/livros\/engenhariadesoftware\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/elemarjr.com\/livros\/engenhariadesoftware\/wp-json\/wp\/v2\/comments?post=5501"}],"version-history":[{"count":12,"href":"https:\/\/elemarjr.com\/livros\/engenhariadesoftware\/wp-json\/wp\/v2\/posts\/5501\/revisions"}],"predecessor-version":[{"id":5518,"href":"https:\/\/elemarjr.com\/livros\/engenhariadesoftware\/wp-json\/wp\/v2\/posts\/5501\/revisions\/5518"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/elemarjr.com\/livros\/engenhariadesoftware\/wp-json\/wp\/v2\/media\/5515"}],"wp:attachment":[{"href":"https:\/\/elemarjr.com\/livros\/engenhariadesoftware\/wp-json\/wp\/v2\/media?parent=5501"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/elemarjr.com\/livros\/engenhariadesoftware\/wp-json\/wp\/v2\/categories?post=5501"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/elemarjr.com\/livros\/engenhariadesoftware\/wp-json\/wp\/v2\/tags?post=5501"},{"taxonomy":"url","embeddable":true,"href":"https:\/\/elemarjr.com\/livros\/engenhariadesoftware\/wp-json\/wp\/v2\/url?post=5501"},{"taxonomy":"apendices","embeddable":true,"href":"https:\/\/elemarjr.com\/livros\/engenhariadesoftware\/wp-json\/wp\/v2\/apendices?post=5501"},{"taxonomy":"capitulos","embeddable":true,"href":"https:\/\/elemarjr.com\/livros\/engenhariadesoftware\/wp-json\/wp\/v2\/capitulos?post=5501"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}

\"\"<\/a><\/p>\n