{"id":87,"date":"2020-11-21T16:04:28","date_gmt":"2020-11-21T16:04:28","guid":{"rendered":"https:\/\/efelti.com\/tech\/?p=87"},"modified":"2020-11-22T11:49:30","modified_gmt":"2020-11-22T11:49:30","slug":"trunk-based-development-healthy-branching-model","status":"publish","type":"post","link":"https:\/\/efelti.com\/tech\/?p=87","title":{"rendered":"Trunk Based Development &#038; Healthy Branching Model"},"content":{"rendered":"\n<p>If we are talking about <strong>Brancing Models<\/strong> in Software Development, like GitFlow, GitHub Flow, etc., <strong>Trunk Based Development<\/strong> (<strong>TBD<\/strong>) comes out as an important Brancing Model.<\/p>\n\n\n\n<p>Stated in 2017 State of DevOps Report <strong>TBD<\/strong> is correlated with <strong>high performance teams<\/strong> and a factor that <strong>positively contribute to Continuous Delivery<\/strong> <a href=\"https:\/\/www.linkedin.com\/pulse\/state-devops-reports-2017-trunk-based-development-practices-lopez\/\">https:\/\/www.linkedin.com\/pulse\/state-devops-reports-2017-trunk-based-development-practices-lopez\/<\/a>.<\/p>\n\n\n\n<p>However, in my experience of adopting <strong>TBD<\/strong> in my Software Development Team, there were some so uneasy thing related to <strong>mindset<\/strong> change which is required for TBD, that although the team said that they were adopting TBD, but in the practice they are still doing <strong>antipattern<\/strong> of TBD.<\/p>\n\n\n\n<p>Moreover, <strong>disbelieve<\/strong> &amp; <strong>resistance<\/strong> have been observed about the concept, many times those were shouted about the <strong>How<\/strong>.<\/p>\n\n\n\n<p>In this article, since we know that TBD is famous as a key enabler of&nbsp;<a href=\"https:\/\/trunkbaseddevelopment.com\/continuous-integration\/\">Continuous Integration<\/a>&nbsp;and by extension&nbsp;<a href=\"https:\/\/trunkbaseddevelopment.com\/continuous-delivery\/\">Continuous Delivery<\/a>, I will talk about:<\/p>\n\n\n\n<ul class=\"wp-block-list\"><li>the <strong>Issues<\/strong> if we continue the <strong>Feature Based Development WITHOUT<\/strong> the <strong>Trunk Based Development<\/strong> and <strong>HOW Trunk Based Development<\/strong> solves it to <strong>understand the concepts<\/strong><\/li><li>I will talk a bit about <strong>WHAT IS<\/strong> Trunk Based Development to differentiate with <strong>WHAT is NOT<\/strong><\/li><li>I will talk about the <strong>Issues<\/strong> in adopting <strong>Trunk Based Development<\/strong> and <strong>HOW<\/strong> are <strong>the practices to solve it<\/strong>. We will talk a bit about Feature Toggles, Branch by Abstraction, and Development plan by using Black Boxing such as Flow Based Programming.<\/li><\/ul>\n\n\n\n<h2 class=\"wp-block-heading\">Issues in Feature Based Development with Long Living Branches<\/h2>\n\n\n\n<p>Long lived feature branch implicates long period of time without feedback. And also developers who normally work with long living feature branches also tends to have a big black box of implementation. It is even worse if the user story is not sliced small. There are tendencies to have a big implementation which in worst case not closed within a cadence such as a scrum sprint.<\/p>\n\n\n\n<p>It causes <strong>absence of visibilities<\/strong> to Developers of Team Members, but also to Product Owner or other stakeholders about the progress causing anxiety within team and sometimes loss of trust but also loss of good feeling of tracking and estimation within the developers and the team members themselves.<\/p>\n\n\n\n<p>In case you also adopt <strong>Code Review Process<\/strong>, the Code Review Process is also becomes difficult and often there are some <strong>innertia<\/strong> within the developers to review, since it takes a lot of time of reviewing a big implementation.<\/p>\n\n\n\n<p>For teams who still not adopts TDD \/ Test Driven Development, there is also tendency that <strong>unit tests also come late<\/strong>, since psychologically people tend to be more lazy to write test code, before feature is completely done. Tests come even late in development tests.<\/p>\n\n\n\n<p>Merge conflicts problems (<strong>unproductive merge<\/strong>) also often occurs. Some <strong>element of (negative) surprises<\/strong> as well because <strong>tests come late<\/strong> (<strong>no shift left culture<\/strong>), generally it causes late feedback.<\/p>\n\n\n\n<p>Since there are less merge into code base (master \/ trunk branch), if feature is an epic, there normally nothing to release even after several days \/ weeks, which implicates <strong>NO \/ low level of continuous delivery<\/strong> and the deployments \/ releases also become <strong>high risk deployments<\/strong> because we need to do bigger releases instead of releasing small-small things incrementally.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">Issues of Fixing Issues Directly in Release \/ Production Issue Branches<\/h2>\n\n\n\n<p><strong>Release Branches<\/strong> and <strong>Hotfix Branches<\/strong> are a common concept if you are working with branching models like GitFlow, GitHub Flow, or other Feature Based Development.<\/p>\n\n\n\n<p>So far F<strong>eature Based Development<\/strong> mostly teaches about how to structure branches but does <strong>NOT teach about healthy branching model<\/strong>.<\/p>\n\n\n\n<p>Another problems which often occur, that people often fix directly issues in release branches or hotfix branches but they <strong>forget to merge them back<\/strong> to their code base and moreover <strong>forget test the code base<\/strong> again after merge, causing more production issues to be fixed, since we would put focus on Release Branches and Hotfix Branches instead of focus on Code Base \/ Trunk.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">Trunk Based Development Essential Concept<\/h2>\n\n\n\n<p>Feature Based Development talks about How to Branch, TBD is talking about <strong>Healthy Branch<\/strong>:<\/p>\n\n\n\n<ul class=\"wp-block-list\"><li><strong>Short Living Feature Branches<\/strong> by <strong>one<\/strong> developer \/ one pair \/ one mob (and <strong>NOT<\/strong> multiple parallel persons)<\/li><li><strong>Fix to Code Base first before fixing the others<\/strong><\/li><\/ul>\n\n\n\n<p>We can group them to 3 Keys Activities:<\/p>\n\n\n\n<ul class=\"wp-block-list\"><li>Development, including <strong>Bug<\/strong>-Fixing<\/li><li>Releasing<\/li><li><strong>Hot<\/strong>-Fixing<\/li><\/ul>\n\n\n\n<figure class=\"wp-block-image size-large\"><img loading=\"lazy\" decoding=\"async\" width=\"852\" height=\"429\" src=\"https:\/\/efelti.com\/tech\/wp-content\/uploads\/2020\/11\/TBD.png\" alt=\"\" class=\"wp-image-88\" srcset=\"https:\/\/efelti.com\/tech\/wp-content\/uploads\/2020\/11\/TBD.png 852w, https:\/\/efelti.com\/tech\/wp-content\/uploads\/2020\/11\/TBD-300x151.png 300w, https:\/\/efelti.com\/tech\/wp-content\/uploads\/2020\/11\/TBD-768x387.png 768w, https:\/\/efelti.com\/tech\/wp-content\/uploads\/2020\/11\/TBD-100x50.png 100w\" sizes=\"auto, (max-width: 852px) 100vw, 852px\" \/><\/figure>\n\n\n\n<h3 class=\"wp-block-heading\">Development<\/h3>\n\n\n\n<ul class=\"wp-block-list\"><li>Short-lived feature (\/ bugfix) branches: <strong>no longer than 2 days<\/strong> (<strong>longer<\/strong> =&gt; <strong>anti-thesis<\/strong> of TBD)<\/li><li>Each branch by 1 activity, NOT parallel activities (NOT by multiple developers working in parallel)<\/li><li>Merged code in Trunk \/ Master doesn\u2019t break the master, and <strong>master is in releasable state<\/strong><\/li><li>Any feature longer than 2 days, to be <strong>broken down<\/strong> (<strong>by abstraction<\/strong>) to shorter feature branches<\/li><\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Releasing &amp; Hot-Fixing<\/h3>\n\n\n\n<ul class=\"wp-block-list\"><li>Release \/ hotfix branch (<a href=\"https:\/\/trunkbaseddevelopment.com\/branch-for-release\/\" target=\"_blank\" rel=\"noreferrer noopener\">https:\/\/trunkbaseddevelopment.com\/branch-for-release\/<\/a>) is there only when necessary, on incompatible policy, late, and to avoid freeze<\/li><li>In case of using release \/ hotfix branches, fixing is to be done &amp; tested in <strong>both<\/strong> release \/ hotfix branch(es) and trunk (master)<ul><li>Since people tend to not fixing (or forget) into master, the policy says, <strong>fix<\/strong> it in <strong>trunk \/ master first<\/strong> than (cherry) pick it to the release \/ hotfix branch(es) so we have the fix in all required places<\/li><\/ul><\/li><\/ul>\n\n\n\n<h2 class=\"wp-block-heading\">What is NOT a Trunk Based Development<\/h2>\n\n\n\n<ul class=\"wp-block-list\"><li>Merely naming code base as Trunk, without doing TBD Mindset<\/li><li>Feature (\/ bugfix) Branches is longer than 2 days<\/li><li>A Single Branch is done by parallel activities \/ multiple developers (which are not as a Pair \/ as a Mob)<\/li><li>Every day not being the same for developers for a Single Branch<\/li><li>Fixing code in Release Branch \/ Hot-fix Branch directly<\/li><li>Merging fix instead cherry-picking<\/li><li>Merge to master within less the 2 days but not ensuring it does not break the code base (only because of the urge)<\/li><\/ul>\n\n\n\n<p>More info, please visit <a href=\"https:\/\/trunkbaseddevelopment.com\/youre-doing-it-wrong\/\" target=\"_blank\" rel=\"noreferrer noopener\">https:\/\/trunkbaseddevelopment.com\/youre-doing-it-wrong\/<\/a><\/p>\n\n\n\n<h2 class=\"wp-block-heading\">What would happen if we do TBD<br>(Why we would love it)<\/h2>\n\n\n\n<ul class=\"wp-block-list\"><li>You\u2019ll <strong>Integrate<\/strong> Code <strong>Continuously<\/strong> (at least each 2 days)<\/li><li>You\u2019ll Have <strong>Eager Code review<\/strong> and <strong>Continuous Code Review<\/strong><ul><li>Small reviews ensure it to make it possible<\/li><li>Dev Team Member is forced to do it efficiently and get used to it<\/li><\/ul><\/li><li>You\u2019ll <strong>Release<\/strong> Application Changes <strong>Consecutively<\/strong><ul><li>Code base (trunk \/ master) is (near) always releasable and has always something new to release (at least each 2 days)<\/li><\/ul><\/li><li>You\u2019ll <strong>Gradually Introduce New Features<\/strong><ul><li><strong>Product Owner<\/strong>, stakeholders will be <strong>happy<\/strong> instead of living in anxiety<\/li><li><strong>Devevelopers<\/strong> will be <strong>proud<\/strong> of their <strong>productivity<\/strong><\/li><li>Since the Product Owner and Developers are happy &amp; productive, <strong>Scrum Master<\/strong> will be also proud and happy<\/li><\/ul><\/li><\/ul>\n\n\n\n<p>Read more: <a rel=\"noreferrer noopener\" href=\"https:\/\/rollout.io\/blog\/trunk-based-development-what-why\/\" target=\"_blank\">https:\/\/rollout.io\/blog\/trunk-based-development-what-why\/<\/a><\/p>\n\n\n\n<h2 class=\"wp-block-heading\">Some Issues in Adopting TBD<\/h2>\n\n\n\n<ul class=\"wp-block-list\"><li>Implementation should not be released to public but deployment should happen<\/li><li>A feature to implement are much more longer than 2 days<\/li><li>Implementations are finished not in the same time &amp; broken code shouldn\u2019t jeopardize the code base \/ trunk<\/li><li>Not sure how to scope the feature branch<\/li><\/ul>\n\n\n\n<p>Those issues above often occur and remain unsolved by developers causing skepticism to TBD because the developers do not knowing the HOW. In next section we will talk about the HOW.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">TBD: The HOW<\/h2>\n\n\n\n<ul class=\"wp-block-list\"><li><strong>Problem<\/strong>: Implementation should not be released to public but deployment should happen<ul><li><strong>A Solution<\/strong>: Concept of <strong>Feature Toggles<\/strong>. Separating publishing from deployment<\/li><\/ul><\/li><li><strong>Problem<\/strong>: Features to implement are much more longer than 2 days. Implementations are finished not in the same time &amp; broken code shouldn\u2019t jeopardize the code base \/ trunk<ul><li><strong>A Solution<\/strong>: Concept of <strong>Branch by Abstraction<\/strong>. Have an abstraction around code to be able to switch code between new implementation and legacy code, so new merged code doesn\u2019t disrupt existing code<\/li><\/ul><\/li><li><strong>Problem<\/strong>: Not sure how to scope the feature branch<ul><li><strong>A Solution<\/strong>: <strong>Split big implementation<\/strong> to smaller chunk using black-boxing concept, e.g. Flow Based Programming. <strong>Split bigger tasks to smaller sequence<\/strong> of task list<\/li><\/ul><\/li><\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">The How: Feature Toggle<\/h3>\n\n\n\n<p>How we think about feature toggles (the prejudice): Feature toggle is complicated \u25e6It takes a lot of effort. <\/p>\n\n\n\n<p>Some perspective which would let us rethink: There are many kinds of feature toggles: <a href=\"https:\/\/martinfowler.com\/articles\/feature-toggles.html\" target=\"_blank\" rel=\"noreferrer noopener\">https:\/\/martinfowler.com\/articles\/feature-toggles.html<\/a><\/p>\n\n\n\n<ul class=\"wp-block-list\"><li>static toggles vs dynamic toggles<\/li><li>Long-lived toggles vs transient toggles<ul><li>Why put to much effort to transient toggles, if after a few days, or 1 or 2 weeks you remove it anyway<\/li><\/ul><\/li><\/ul>\n\n\n\n<p>Not all toggling-off has an effort, some are naturally off: A new class of a function which is complete &amp; tested as a new feature but not yet called implies it is off. A new API which is not yet exposed to the API gateway, implies that the API is still off from outside.<\/p>\n\n\n\n<figure class=\"wp-block-image size-large\"><img loading=\"lazy\" decoding=\"async\" width=\"600\" height=\"447\" src=\"https:\/\/efelti.com\/tech\/wp-content\/uploads\/2020\/11\/Feature-Toggle.png\" alt=\"\" class=\"wp-image-89\" srcset=\"https:\/\/efelti.com\/tech\/wp-content\/uploads\/2020\/11\/Feature-Toggle.png 600w, https:\/\/efelti.com\/tech\/wp-content\/uploads\/2020\/11\/Feature-Toggle-300x224.png 300w, https:\/\/efelti.com\/tech\/wp-content\/uploads\/2020\/11\/Feature-Toggle-100x75.png 100w, https:\/\/efelti.com\/tech\/wp-content\/uploads\/2020\/11\/Feature-Toggle-110x83.png 110w\" sizes=\"auto, (max-width: 600px) 100vw, 600px\" \/><figcaption>From: <a href=\"https:\/\/martinfowler.com\/articles\/feature-toggles.html\" target=\"_blank\" rel=\"noreferrer noopener\">https:\/\/martinfowler.com\/articles\/feature-toggles.html<\/a><\/figcaption><\/figure>\n\n\n\n<h3 class=\"wp-block-heading\">The How: Branch by Abstraction<\/h3>\n\n\n\n<p>Branch by Abstraction is:= creating abstraction to keep legacy code and new code switchable, so development does not jeopardize integrated trunk code.<\/p>\n\n\n\n<p>Steps citated from (<a rel=\"noreferrer noopener\" href=\"https:\/\/trunkbaseddevelopment.com\/branch-by-abstraction\/\" target=\"_blank\">https:\/\/trunkbaseddevelopment.com\/branch-by-abstraction\/<\/a>):<\/p>\n\n\n\n<ol class=\"wp-block-list\"><li>Introduce an abstraction around the code that is to be replaced, and commit that for all to see. If needed, this can take multiple commits. None of those are allowed to break the build, and all of them could be pushed to the shared repository in order, and as done.<\/li><li>Write a second implementation of the abstraction for the to-be-introduced code, and commit that, but maybe as \u2018turned off\u2019 within the trunk so that other developers are not depending on it yet. If needed, this can take multiple commits as above. The abstraction from #1 may also be occasionally tweaked, but must follow the same rule &#8211; do not break the build.<\/li><li>Flip the software \u2018off\u2019 switch to \u2018on\u2019 for the rest of the team, and commit\/push that.<\/li><li>Remove the to-be-replaced implementation<\/li><li>Remove the abstraction<\/li><\/ol>\n\n\n\n<figure class=\"wp-block-image size-large\"><img loading=\"lazy\" decoding=\"async\" width=\"745\" height=\"343\" src=\"https:\/\/efelti.com\/tech\/wp-content\/uploads\/2020\/11\/Branch-by-Abstraction.png\" alt=\"\" class=\"wp-image-90\" srcset=\"https:\/\/efelti.com\/tech\/wp-content\/uploads\/2020\/11\/Branch-by-Abstraction.png 745w, https:\/\/efelti.com\/tech\/wp-content\/uploads\/2020\/11\/Branch-by-Abstraction-300x138.png 300w, https:\/\/efelti.com\/tech\/wp-content\/uploads\/2020\/11\/Branch-by-Abstraction-100x46.png 100w\" sizes=\"auto, (max-width: 745px) 100vw, 745px\" \/><figcaption>From: <a href=\"https:\/\/trunkbaseddevelopment.com\/branch-by-abstraction\/\" target=\"_blank\" rel=\"noreferrer noopener\">https:\/\/trunkbaseddevelopment.com\/branch-by-abstraction\/<\/a><\/figcaption><\/figure>\n\n\n\n<h3 class=\"wp-block-heading\">The How: Split to Smaller Black-boxes<\/h3>\n\n\n\n<figure class=\"wp-block-image size-large\"><img loading=\"lazy\" decoding=\"async\" width=\"368\" height=\"147\" src=\"https:\/\/efelti.com\/tech\/wp-content\/uploads\/2020\/11\/Black-Box.png\" alt=\"\" class=\"wp-image-91\" srcset=\"https:\/\/efelti.com\/tech\/wp-content\/uploads\/2020\/11\/Black-Box.png 368w, https:\/\/efelti.com\/tech\/wp-content\/uploads\/2020\/11\/Black-Box-300x120.png 300w, https:\/\/efelti.com\/tech\/wp-content\/uploads\/2020\/11\/Black-Box-100x40.png 100w\" sizes=\"auto, (max-width: 368px) 100vw, 368px\" \/><\/figure>\n\n\n\n<p>A bigger tasks can be <strong>split<\/strong> to smaller <strong>independent<\/strong> tasks<\/p>\n\n\n\n<p>Steps:<\/p>\n\n\n\n<ul class=\"wp-block-list\"><li>Instead of flow with the work, <strong>plan our work<\/strong><\/li><li>Create a <strong>checklist<\/strong> and <strong>sequences<\/strong><\/li><li>Create <strong>black-boxes<\/strong><ul><li>A black-box mathematically can be seen as a function with input and output<\/li><li>Understand &amp; learn <strong>Flow Based Programming<\/strong><ul><li>By necessity draw interconnectivity<br>with <strong>FBP Diagram<\/strong>, <strong>UML diagrams<\/strong><br>(class diagram, activity diagram) <\/li><li><a href=\"https:\/\/en.wikipedia.org\/wiki\/Flow-based_programming\">https:\/\/en.wikipedia.org\/wiki\/Flow-based_programming<\/a> <\/li><\/ul><\/li><li>Apply SOLID principle<ul><li>1 Responsibility Classes (small decoupled classes),<br>Interfacings, Dependency Injections<\/li><\/ul><\/li><li>In case collaboration needed, is useful to define contracts, so subtasks can be <strong>distributed<\/strong> among team members =&gt;<ul><li><strong>More people<\/strong> could work for <strong>a same goal<\/strong><\/li><li><strong>Value<\/strong> delivered <strong>faster<\/strong> (which support <strong>agile<\/strong> including <strong>scrum<\/strong>), than everyone works in separate pipelines (which is a <strong>scrum antipattern<\/strong>)<\/li><li>Teams has <strong>visibilities<\/strong> of what to be done and have been done<\/li><\/ul><\/li><\/ul><\/li><\/ul>\n\n\n\n<figure class=\"wp-block-image size-large\"><img loading=\"lazy\" decoding=\"async\" width=\"258\" height=\"275\" src=\"https:\/\/efelti.com\/tech\/wp-content\/uploads\/2020\/11\/A-Function.png\" alt=\"\" class=\"wp-image-92\" srcset=\"https:\/\/efelti.com\/tech\/wp-content\/uploads\/2020\/11\/A-Function.png 258w, https:\/\/efelti.com\/tech\/wp-content\/uploads\/2020\/11\/A-Function-94x100.png 94w\" sizes=\"auto, (max-width: 258px) 100vw, 258px\" \/><\/figure>\n\n\n\n<h4 class=\"wp-block-heading\">Black-boxing Example: Listing &amp; Sequencing<\/h4>\n\n\n\n<p>This is an example of breaking a branch, instead of having 1 single big branch named <strong>similarity address validation<\/strong> to have near 20 planned branches \/ activities:<\/p>\n\n\n\n<ol class=\"wp-block-list\"><li>elastic search microservice setup<\/li><li>setup of elastic search<\/li><li>integration of elastic search to microservice<\/li><li>create single indexing API (Create)<\/li><li>create batch indexing API (Initialize)<\/li><li>create database export script<\/li><li>create search API (Read)<\/li><li>create update or deletion API (Update &amp; Delete)<\/li><li>create address similarity logic<\/li><li>integrate address similarity logic with search API create approval rejection logic<\/li><li>integrate address similarity to approval and rejection validation<\/li><li>create approval and rejection logger<\/li><li>integrate logging for approval and rejection<\/li><li>integrate indexing of address in submission<\/li><li>integrate update in policy status synchronization<\/li><li>create index update logger<\/li><li>integrate index update logger to submission integrate index update logger to policy status synchronization<\/li><\/ol>\n\n\n\n<h4 class=\"wp-block-heading\">Black-boxing Example: Dependency Analysis<\/h4>\n\n\n\n<p>Create a plan of dependency analysis to optimize collaboration.<\/p>\n\n\n\n<p>An example of dependency \/ sequence analysis diagram:<\/p>\n\n\n\n<figure class=\"wp-block-image size-large\"><img loading=\"lazy\" decoding=\"async\" width=\"864\" height=\"679\" src=\"https:\/\/efelti.com\/tech\/wp-content\/uploads\/2020\/11\/Dependency-Analysis.png\" alt=\"\" class=\"wp-image-94\" srcset=\"https:\/\/efelti.com\/tech\/wp-content\/uploads\/2020\/11\/Dependency-Analysis.png 864w, https:\/\/efelti.com\/tech\/wp-content\/uploads\/2020\/11\/Dependency-Analysis-300x236.png 300w, https:\/\/efelti.com\/tech\/wp-content\/uploads\/2020\/11\/Dependency-Analysis-768x604.png 768w, https:\/\/efelti.com\/tech\/wp-content\/uploads\/2020\/11\/Dependency-Analysis-100x79.png 100w\" sizes=\"auto, (max-width: 864px) 100vw, 864px\" \/><\/figure>\n\n\n\n<ul class=\"wp-block-list\"><li>The green ones are the independent sub tasks<\/li><li>The yellow ones are dependent from the box before<\/li><li>Once a green box is done, next green box could be defined so more independent sub-tasks can be redistributed<\/li><li>We can choose which tasks based on dependency to remove so called critical paths problems<\/li><\/ul>\n\n\n\n<h4 class=\"wp-block-heading\">Black-boxing Example: Flow Based Programming Plan<\/h4>\n\n\n\n<p>By having those boxes in the previous section you can create a blackbox function to classes in code.<\/p>\n\n\n\n<ul class=\"wp-block-list\"><li><strong>Black-boxing<\/strong> to <strong>classes<\/strong> (Single Responsibility)<ul><li>Don\u2019t touch existing class but create a new one for a new behavior<\/li><li>Inject with dependency injection to avoid complexity &amp; ensure decoupling<\/li><\/ul><\/li><li>Analyze <strong>Input Parameters<\/strong> and <strong>Output Returns<\/strong><\/li><li>Use <strong>DTO concept<\/strong> and <strong>function concept<\/strong> to define <strong>data contract<\/strong> and <strong>functional contract<\/strong><\/li><li>Use <strong>transformer concept<\/strong> to translate outputs to inputs for integration<\/li><\/ul>\n\n\n\n<p>By having those separation developers can collaborate together for a same goal but in separated branches and decoupled codes.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">The How: Assess Refactoring Effort instead Avoiding It<\/h3>\n\n\n\n<p>Another rejection comes often out from developers are refactoring effort. For this, take into account that even in a very good plan, <strong>refactoring<\/strong> might happen \/ necessary.<\/p>\n\n\n\n<p>Do NOT try to exclude the effort of refactoring, but <strong>assess<\/strong>, and <strong>accept<\/strong> it as long as refactoring is supporting that value is to be delivered faster (more productive, economic, and beneficial).<\/p>\n\n\n\n<p>Even TDD include refactoring in the process steps (Cycle of: Create Test, Implement, Refactor).<\/p>\n\n\n\n<p>Adopt solid principle so that refactoring effort will be reduced and code will be easier decouplable.<\/p>\n\n\n\n<p>Spare our time to plan input output contract before continue development, so simplicity will be more visible across team members and refactoring effort will be reduced.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">Summary<\/h2>\n\n\n\n<ul class=\"wp-block-list\"><li>Strive to <strong>short-lived feature branch<\/strong> which is by <strong>one<\/strong> person \/ pair \/ mob (<strong>NOT<\/strong> parallel persons)<\/li><li><strong>Single code base<\/strong> named trunk \/ master as our focus (<strong>NOT<\/strong> feature branches)<\/li><li><strong>Fix master first<\/strong> before release branch \/ hotfix branch so we won\u2019t forget<\/li><li>Always consider <strong>feature toggle<\/strong> so code base is <strong>always releasable<\/strong>, and <strong>supporting legacy<\/strong> until it is really ready<\/li><li>Create <strong>abstraction of branches<\/strong> to support legacy until things are stabilized<\/li><li>Break down a big branch to <strong>black-boxes<\/strong><\/li><li>Create <strong>checklist<\/strong> and <strong>sequences<\/strong><\/li><li>By necessity define <strong>dependencies<\/strong> so we can <strong>distribute subtasks<\/strong> so team can work for a <strong>same goal<\/strong> instead separate pipelines so <strong>values<\/strong> can be <strong>delivered faster<\/strong><\/li><li>For unclear contract, <strong>deep dive<\/strong> by creating <strong>black-boxes plan<\/strong> to define <strong>inputs<\/strong> &amp; <strong>outputs<\/strong> and relation<\/li><li>Consider that <strong>refactoring<\/strong> is <strong>NOT<\/strong> something to avoid <strong>BUT<\/strong> to assess (how much and how to optimize)<\/li><li>Use <strong>SOLID principle<\/strong> for this<\/li><li>Use <strong>black-boxing<\/strong> and <strong>transformer<\/strong> concept of <strong>Flow Based Programming<\/strong><\/li><li>TBD is <strong>more<\/strong> than <strong>Branching Model<\/strong>, but also <strong>Mindsets<\/strong><\/li><\/ul>\n\n\n\n<h2 class=\"wp-block-heading\">Something to confuse us, so we reflect ourselves<\/h2>\n\n\n\n<ul class=\"wp-block-list\"><li>We are often trapped in wordings and terms =&gt; Be careful so we shouldn\u2019t be trapped<\/li><li>Do we abandon <strong>Feature Based Development<\/strong>?<\/li><li>Is <strong>Trunk Based Development<\/strong> <strong><span style=\"text-decoration: underline;\">NOT<\/span><\/strong> Feature Based Development?<\/li><li>Featured Based Development teaches us how to split requirement to features<\/li><li>Trunk Based Development teaches us how to keep the branches healthy<\/li><li>We can work with TBD and Short-Lived Feature Branches which are features but max of each just lives for 2 days, so we still use concept of features but in healthy way and throw away the unhealthy<\/li><li>Martin Fowler wrote this article: <a href=\"https:\/\/martinfowler.com\/articles\/branching-patterns.html\">https:\/\/martinfowler.com\/articles\/branching-patterns.html<\/a><ul><li>In my opinion, he seems doesn\u2019t care which policy you follow, either git-flow or TBD or both, but he seems to follow short-lived branch concept and has the focus of single based code he named mainline to keep healthy branches and healthy development. He even has given an own name of the concept for it, importantly to support Continuous Integration and Continuous Delivery and Productive Development<\/li><\/ul><\/li><\/ul>\n\n\n\n<h2 class=\"wp-block-heading\">My Wish &amp; Hope<\/h2>\n\n\n\n<ul class=\"wp-block-list\"><li>Now we know about the importance of Healthy Branching Model where Trunk Based Development could support it<\/li><li>We know what is healthy what is not<\/li><li>\u201cTrunk-based development is a substantial change for many developers, and you should expect some resistance. Many developers simply can&#8217;t imagine working in this way. A good practice is to find developers who have worked in this way, and have them coach other developers.\u201d <ul><li><a href=\"https:\/\/cloud.google.com\/solutions\/devops\/devops-tech-trunk-based-development\">https:\/\/cloud.google.com\/solutions\/devops\/devops-tech-trunk-based-development<\/a><\/li><\/ul><\/li><li>I hope this article could reduce misconceptions of TBD, so that we have the correct understanding of the concept<\/li><li>Hopefully we are amazed about some hidden concepts of Why and How, and start now with <strong>Believe<\/strong> and <strong>Effort<\/strong> instead of <s><u><strong>Prejudice<\/strong><\/u><\/s> and <s><u><strong>Disbelieve<\/strong><\/u><\/s><\/li><li>There will be a process instead of from today to tomorrow so we should <strong>strive ourselves<\/strong>, be <strong>solution oriented<\/strong>, and <strong>help each others<\/strong> to solve the issues together for <strong>improved productivity<\/strong> for our <strong>team\u2019s success<\/strong><\/li><\/ul>\n\n\n\n<h2 class=\"wp-block-heading\">Trunk Based Development Cheatsheet<\/h2>\n\n\n\n<figure class=\"wp-block-image size-large\"><img loading=\"lazy\" decoding=\"async\" width=\"1024\" height=\"614\" src=\"https:\/\/efelti.com\/tech\/wp-content\/uploads\/2020\/11\/TBD-Map-1024x614.png\" alt=\"\" class=\"wp-image-99\" srcset=\"https:\/\/efelti.com\/tech\/wp-content\/uploads\/2020\/11\/TBD-Map-1024x614.png 1024w, https:\/\/efelti.com\/tech\/wp-content\/uploads\/2020\/11\/TBD-Map-300x180.png 300w, https:\/\/efelti.com\/tech\/wp-content\/uploads\/2020\/11\/TBD-Map-768x461.png 768w, https:\/\/efelti.com\/tech\/wp-content\/uploads\/2020\/11\/TBD-Map-100x60.png 100w, https:\/\/efelti.com\/tech\/wp-content\/uploads\/2020\/11\/TBD-Map.png 1062w\" sizes=\"auto, (max-width: 1024px) 100vw, 1024px\" \/><\/figure>\n\n\n\n<h2 class=\"wp-block-heading\">Other References<\/h2>\n\n\n\n<ul class=\"wp-block-list\"><li>Trunk Based Development: <a href=\"https:\/\/trunkbaseddevelopment.com\/\">https:\/\/trunkbaseddevelopment.com\/<\/a><ul><li>You think you do TBD, but it\u2019s not: <a href=\"https:\/\/trunkbaseddevelopment.com\/youre-doing-it-wrong\/\">https:\/\/trunkbaseddevelopment.com\/youre-doing-it-wrong\/<\/a><\/li><li>Releasing: <a href=\"https:\/\/trunkbaseddevelopment.com\/branch-for-release\/\">https:\/\/trunkbaseddevelopment.com\/branch-for-release\/<\/a><\/li><li>ThoughtWorks Article: <a href=\"https:\/\/www.thoughtworks.com\/insights\/blog\/enabling-trunk-based-development-deployment-pipelines\">https:\/\/www.thoughtworks.com\/insights\/blog\/enabling-trunk-based-development-deployment-pipelines<\/a><\/li><li>Continuous Integration and Feature Branching: <a href=\"http:\/\/www.davefarley.net\/?p=247\">http:\/\/www.davefarley.net\/?p=247<\/a><\/li><li>Why I love Trunk Based Development: <a href=\"https:\/\/medium.com\/@mattia.battiston\/why-i-love-trunk-based-development-641fcf0b94a0\">https:\/\/medium.com\/@mattia.battiston\/why-i-love-trunk-based-development-641fcf0b94a0<\/a><\/li><\/ul><\/li><li>Feature Toggle: <a href=\"https:\/\/martinfowler.com\/articles\/feature-toggles.html\">https:\/\/martinfowler.com\/articles\/feature-toggles.html<\/a><ul><li>From TBD website: <a href=\"https:\/\/trunkbaseddevelopment.com\/feature-flags\/\">https:\/\/trunkbaseddevelopment.com\/feature-flags\/<\/a><\/li><\/ul><\/li><\/ul>\n","protected":false},"excerpt":{"rendered":"<p>If we are talking about Brancing Models in Software Development, like GitFlow, GitHub Flow, etc., Trunk Based Development (TBD) comes out as an important Brancing Model. Stated in 2017 State of DevOps Report TBD is correlated with high performance teams and a factor that positively contribute to Continuous Delivery https:\/\/www.linkedin.com\/pulse\/state-devops-reports-2017-trunk-based-development-practices-lopez\/. However, in my experience of [&hellip;]<\/p>\n","protected":false},"author":1,"featured_media":101,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[9,4,13,10],"tags":[11,20,24,22,2,21,23,14,12],"class_list":["post-87","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-agile","category-clean-code","category-extreme-programming-xp","category-scrum","tag-agile","tag-branching-model","tag-cheatsheet","tag-ci-cd","tag-clean-code","tag-continuous-delivery","tag-devops","tag-extreme-programming-xp","tag-scrum"],"_links":{"self":[{"href":"https:\/\/efelti.com\/tech\/index.php?rest_route=\/wp\/v2\/posts\/87","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/efelti.com\/tech\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/efelti.com\/tech\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/efelti.com\/tech\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/efelti.com\/tech\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=87"}],"version-history":[{"count":5,"href":"https:\/\/efelti.com\/tech\/index.php?rest_route=\/wp\/v2\/posts\/87\/revisions"}],"predecessor-version":[{"id":104,"href":"https:\/\/efelti.com\/tech\/index.php?rest_route=\/wp\/v2\/posts\/87\/revisions\/104"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/efelti.com\/tech\/index.php?rest_route=\/wp\/v2\/media\/101"}],"wp:attachment":[{"href":"https:\/\/efelti.com\/tech\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=87"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/efelti.com\/tech\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=87"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/efelti.com\/tech\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=87"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}