{"id":5464,"date":"2022-08-10T11:06:34","date_gmt":"2022-08-10T14:06:34","guid":{"rendered":"https:\/\/elemarjr.com\/engenhariadesoftware\/?p=5464"},"modified":"2022-08-10T11:06:34","modified_gmt":"2022-08-10T14:06:34","slug":"git-flow","status":"publish","type":"post","link":"https:\/\/elemarjr.com\/livros\/engenhariadesoftware\/git-flow\/","title":{"rendered":"Colocando a “casa em ordem” com Git Flow"},"content":{"rendered":"

Os reposit\u00f3rios de c\u00f3digo-fonte dos sistemas que uma empresa desenvolve s\u00e3o o “cora\u00e7\u00e3o” da engenharia de software. <\/b><\/p>\n

Empresas maduras na\u00a0capability\u00a0<\/em>de engenharia de software t\u00eam reposit\u00f3rios “saud\u00e1veis”, ou seja, que facilitam a implementa\u00e7\u00e3o \u00e1gil de mudan\u00e7as (implementa\u00e7\u00f5es e corre\u00e7\u00f5es) nos sistemas – com baixo development lead-time<\/em> e alta frequ\u00eancia de deploys\u00a0<\/em>– e facilitam a colabora\u00e7\u00e3o. Por outro lado, reposit\u00f3rios “doentes” dificultam a resolu\u00e7\u00e3o de problemas do dia-a-dia, sendo, inclusive, dif\u00edceis de monitorar, impedindo a ado\u00e7\u00e3o de pr\u00e1ticas reconhecidamente positivas, como\u00a0continuous integration\u00a0<\/em>e\u00a0continuous deployment.<\/em><\/p>\n

\r\n

Continuous Integration (CI), Continuous Delivery e Continuous Deployment (CD)<\/p>\r\n<\/p>\n

Continouous Integration<\/em> (CI) \u00e9 uma pr\u00e1tica de engenharia onde c\u00f3digo \u00e9 integrado em um reposit\u00f3rio compartilhado com maior frequ\u00eancia poss\u00edvel – de prefer\u00eancia v\u00e1rias vezes ao dia. Cada integra\u00e7\u00e3o geralmente \u00e9 verificada por compila\u00e7\u00e3o e testes automatizados.<\/p>\n

Continuous Delivery<\/em> \u00e9 uma extens\u00e3o da Continuous Integration<\/em>, pois implanta automaticamente todas as altera\u00e7\u00f5es de c\u00f3digo em um ambiente de teste e\/ou produ\u00e7\u00e3o ap\u00f3s o est\u00e1gio de compila\u00e7\u00e3o.<\/p>\n

Finalmente, Continuous Deployment\u00a0<\/em>(CD) vai um passo al\u00e9m da Continuous Delivery<\/em>. Com essa pr\u00e1tica, toda mudan\u00e7a que passa por todas as etapas do seu pipeline<\/em> de produ\u00e7\u00e3o \u00e9 liberada para seus clientes. N\u00e3o h\u00e1 interven\u00e7\u00e3o humana e apenas um teste com falha impedir\u00e1 que uma nova altera\u00e7\u00e3o seja implantada na produ\u00e7\u00e3o.<\/p>\n

<\/div>\nReposit\u00f3rios “doentes” raramente s\u00e3o produtos de tecnologias ou ferramentas ruins. Na pr\u00e1tica, o que ocasiona problemas s\u00e3o a falta de pol\u00edticas claras e conduta indisciplinada.\n

\n

Modernamente, a maioria das empresas utiliza alguma implementa\u00e7\u00e3o de git\u00a0<\/em>como base tecnol\u00f3gica para controlar seus reposit\u00f3rios. Uma das abordagens mais efetivas para utilizar\u00a0git\u00a0<\/em>do jeito certo \u00e9 o git flow.<\/em><\/p>\n

\r\n

Git<\/p>\r\n<\/p>\n

Git<\/b> \u00a0\u00e9 um\u00a0sistema de controle de vers\u00f5es\u00a0distribu\u00eddo, usado principalmente no\u00a0desenvolvimento de software, mas pode ser usado para registrar o hist\u00f3rico de edi\u00e7\u00f5es de qualquer tipo de arquivo (Exemplo: alguns livros digitais s\u00e3o disponibilizados no\u00a0GitHub<\/a>\u00a0e escrito aos poucos publicamente).<\/p>\n

O Git foi inicialmente projetado e desenvolvido por\u00a0Linus Torvalds<\/a>\u00a0para o desenvolvimento do\u00a0kernel do Linux<\/em>, mas foi adotado por muitos outros projetos.<\/sup><\/p>\n

<\/div>\n

O que \u00e9 e quando usar “Git flow”<\/em><\/h2>\n

O Git flow\u00a0<\/em>\u00e9 um “modelo opinativo” de trabalho para equipes de engenharia de software que utilizam Git<\/em>.<\/strong> Ele foi idealizado por Vincent Driessen<\/a> em 2010 e se destaca pela fluidez que adiciona ao processo para desenvolvimento de novas funcionalidades, corre\u00e7\u00f5es de bugs\u00a0<\/em>e lan\u00e7amento de vers\u00f5es.<\/p>\n

\r\n\r\n\r\n\r\n
\"\"<\/td>\r\n\"\"\r\n

A successful Git branching model<\/p>\r\n<\/p>\n

Artigo original, escrito por Vincent Drissen<\/a> em 2010, onde ele prop\u00f5e o git flow.\u00a0<\/em>Trata-s de uma excelente refer\u00eancia, detalhada e ilustrada, do modelo.<\/p>\n

\r\n

Acessar artigo<\/a><\/p>\r\n<\/td>\r\n<\/tr>\r\n<\/tbody>\r\n<\/table>\r\n<\/div>\n

O modelo proposto por Drissen, segundo o pr\u00f3prio autor, \u00e9 ideal para projetos que utilizam versionamento sem\u00e2ntico ou quando times precisam suportar v\u00e1rias vers\u00f5es, em produ\u00e7\u00e3o, simultaneamente.<\/p>\n

\r\n

Defini\u00e7\u00e3o: Semantic versioning<\/p>\r\n

<\/p>\n

Semantic versioning \u00e9 uma estrat\u00e9gia para determina\u00e7\u00e3o de vers\u00f5es, utilizando n\u00fameros, em um esquema, MAJOR<\/em>.MINOR<\/em>.PATCH<\/em>, onde deve-se incrementar o major <\/em>quando as mudan\u00e7as implementadas geram incompatibilidade com vers\u00f5es anteriores, minor <\/em>quando forem adicionadas funcionalidades mantendo a compatibilidade e, finalmente, patch<\/em> quando h\u00e1 apenas corre\u00e7\u00e3o de falhas.<\/p>\n

<\/p>\r\n<\/div>\n

Como funciona o “Git Flow<\/em>“<\/h2>\n

O Git Flow<\/em> trabalha com duas branches<\/em> principais, a Develop<\/em> e a Main <\/em>(antigamente Master<\/em>), que s\u00e3o mantidas no reposit\u00f3rio indefinidamente. Al\u00e9m delas recomenda-se manter uma branch\u00a0<\/em>para cada\u00a0release\u00a0<\/em>que se deseja disponibilizar.<\/strong><\/p>\n

A partir das branches <\/em>principais, podem ser criadas outros dois tipos de branches: Feature<\/em>\u00a0e Hotfix<\/em>, tempor\u00e1rias e mantidas at\u00e9 serem mescaladas com as branches<\/em> principais.<\/p>\n

\"\"<\/p>\n

A branch Main\u00a0<\/em>armazena o hist\u00f3rico oficial de lan\u00e7amentos, enquanto a branch\u00a0<\/em>Develop\u00a0<\/em>\u00e9 base para integra\u00e7\u00e3o.\u00a0<\/strong><\/p>\n

Toda vez que uma nova\u00a0feature\u00a0<\/em>for desenvolvida, uma branch\u00a0<\/em>espec\u00edfica deve ser iniciada a partir da branch Develop<\/em>.<\/strong> Idealmente, esta branch\u00a0<\/em>dever\u00e1 ser nomeada conforme padr\u00e3o fixo (ex:\u00a0feature\/<nro. do documento de solicita\u00e7\u00e3o<\/em>). Ela dever\u00e1 existir at\u00e9 que a implementa\u00e7\u00e3o esteja conclu\u00edda quando, ent\u00e3o, dever\u00e1 ser\u00a0mesclada\u00a0<\/em>com a\u00a0branch\u00a0develop<\/em>.<\/p>\n

\r\n\r\n\r\n\r\n
\"\"<\/td>\r\n\"\" O n\u00famero de branches <\/em>Feature <\/em>abertas corresponde ao n\u00famero de funcionalidades que est\u00e3o sendo desenvolvidas simultaneamente. Em times de engenharia que adotam kanban, <\/em>elas ajudam a controlar o Work in Progress.<\/em><\/p>\r\n<\/td>\r\n<\/tr>\r\n<\/tbody>\r\n<\/table>\r\n<\/div>\n

Sempre que uma corre\u00e7\u00e3o imediata, em produ\u00e7\u00e3o, for necess\u00e1ria, uma branch hotfix\u00a0<\/em>deve ser iniciada, a partir da\u00a0Main.<\/em>\u00a0<\/strong>Idealmente, essa branch<\/em> dever\u00e1 ser nomeada conforme padr\u00e3o fixo (ex:\u00a0hotfix\/<nro. do documento de solicita\u00e7\u00e3o><\/em>). Ela dever\u00e1 existir at\u00e9 que a corre\u00e7\u00e3o esteja implementada e pronta para ser integrada tanto na branch Main\u00a0<\/em>quanto\u00a0Develop<\/em>. Al\u00e9m disso, toda vez que for realizado um merge\u00a0\u00a0<\/em>com a\u00a0Main,<\/em> uma tag indicativa de vers\u00e3o dever\u00e1 ser indicada.<\/p>\n

\r\n\r\n\r\n\r\n
\"\"<\/td>\r\n\"\" O n\u00famero de branches <\/em>Hotfix <\/em>abertas corresponde ao n\u00famero de erros em produ\u00e7\u00e3o que est\u00e3o sendo corrigidos simultaneamente. A compara\u00e7\u00e3o entre a quantidade de branches\u00a0<\/em>Feature\u00a0<\/em>e\u00a0Hotfix <\/em>serve como um “retrato” do momento do time.<\/em><\/p>\r\n<\/td>\r\n<\/tr>\r\n<\/tbody>\r\n<\/table>\r\n<\/div>\n

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

A ado\u00e7\u00e3o do\u00a0git flow\u00a0<\/em>oferece excelentes alternativas para coleta duas m\u00e9tricas fundamentais: development lead-time<\/em><\/span> e frequ\u00eancia de<\/span> deploy<\/span>.<\/em><\/strong><\/p>\n

\r\n\r\n\r\n\r\n
\"\"<\/td>\r\n\"\"\r\n

M\u00e9tricas importantes para a engenharia de software<\/p>\r\n

<\/p>\n

Development lead-time<\/em> e frequ\u00eancia de\u00a0deploy\u00a0<\/em>s\u00e3o parte de um conjunto de quatro m\u00e9tricas essenciais para gest\u00e3o de times \u00e1geis.<\/p>\n

Quer saber mais sobre? Leia o t\u00f3pico em que as apresentamos.<\/p>\n

<\/p>\r\nAcessar t\u00f3pico<\/a><\/td>\r\n<\/tr>\r\n<\/tbody>\r\n<\/table>\r\n<\/div>\n

Development lead-time\u00a0<\/em>pode ser “simplificado”, em projetos ativos, para o intervalo de tempo entre\u00a0tags <\/em>indicando vers\u00f5es que introduzem\u00a0features<\/em>. De forma an\u00e1loga, a frequ\u00eancia de\u00a0deploy <\/em>pode ser medida a partir da quantidade de tags <\/em>indicando vers\u00f5es que introduzem features\u00a0<\/em>em um determinado intervalo de tempo (por exemplo, em um m\u00eas).<\/p>\n

Uma restri\u00e7\u00e3o importante<\/h2>\nGit flow\u00a0<\/em>pode ser considerado burocr\u00e1tico demais para empresas com frequ\u00eancias de deploy <\/em>muito altas (v\u00e1rias vezes ao dia, por exemplo). Tal restri\u00e7\u00e3o \u00e9 sinalizada, inclusive pelo criador do modelo.\n

Para pensar…<\/h2>\nGit flow<\/em> \u00e9 um “primeiro passo seguro” para times de engenharia com processos de gest\u00e3o do reposit\u00f3rio desestruturados. Ele estabelece, imediatamente, a implanta\u00e7\u00e3o de pr\u00e1ticas saud\u00e1veis como controle efetivo de vers\u00f5es e coleta de m\u00e9tricas essenciais para a gest\u00e3o.\n
\n

Mesmo com algumas limita\u00e7\u00f5es percept\u00edveis, entendo que o modelo ajuda organiza\u00e7\u00f5es de engenharia a por a “casa em ordem”, habilitando trabalho simult\u00e2neo, colabora\u00e7\u00e3o e suporte para corre\u00e7\u00f5es r\u00e1pidas.<\/p>\n","protected":false},"excerpt":{"rendered":"

Os reposit\u00f3rios de c\u00f3digo-fonte dos sistemas que uma empresa desenvolve s\u00e3o o “cora\u00e7\u00e3o” da engenharia de software. Empresas maduras na\u00a0capability\u00a0de engenharia de software t\u00eam reposit\u00f3rios “saud\u00e1veis”, ou seja, que facilitam a implementa\u00e7\u00e3o \u00e1gil de mudan\u00e7as (implementa\u00e7\u00f5es e corre\u00e7\u00f5es) nos sistemas – com baixo development lead-time e alta frequ\u00eancia de deploys\u00a0– e facilitam a colabora\u00e7\u00e3o. Por […]<\/p>\n","protected":false},"author":2,"featured_media":5483,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[],"tags":[],"url":[72],"apendices":[],"capitulos":[35],"class_list":["post-5464","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","url-permanente","capitulos-capitulo-2-1"],"acf":[],"_links":{"self":[{"href":"https:\/\/elemarjr.com\/livros\/engenhariadesoftware\/wp-json\/wp\/v2\/posts\/5464","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=5464"}],"version-history":[{"count":20,"href":"https:\/\/elemarjr.com\/livros\/engenhariadesoftware\/wp-json\/wp\/v2\/posts\/5464\/revisions"}],"predecessor-version":[{"id":5487,"href":"https:\/\/elemarjr.com\/livros\/engenhariadesoftware\/wp-json\/wp\/v2\/posts\/5464\/revisions\/5487"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/elemarjr.com\/livros\/engenhariadesoftware\/wp-json\/wp\/v2\/media\/5483"}],"wp:attachment":[{"href":"https:\/\/elemarjr.com\/livros\/engenhariadesoftware\/wp-json\/wp\/v2\/media?parent=5464"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/elemarjr.com\/livros\/engenhariadesoftware\/wp-json\/wp\/v2\/categories?post=5464"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/elemarjr.com\/livros\/engenhariadesoftware\/wp-json\/wp\/v2\/tags?post=5464"},{"taxonomy":"url","embeddable":true,"href":"https:\/\/elemarjr.com\/livros\/engenhariadesoftware\/wp-json\/wp\/v2\/url?post=5464"},{"taxonomy":"apendices","embeddable":true,"href":"https:\/\/elemarjr.com\/livros\/engenhariadesoftware\/wp-json\/wp\/v2\/apendices?post=5464"},{"taxonomy":"capitulos","embeddable":true,"href":"https:\/\/elemarjr.com\/livros\/engenhariadesoftware\/wp-json\/wp\/v2\/capitulos?post=5464"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}