Are they the seeds to be nurtured to bring in automation, innovation and transformation. There is a saying, necessity is the mother of invention. I would say, innovation is amalgamation of creativity and necessity. We need to understand the ecosystem, to apply creativity and identify the ideas to bring in change. We need to be competent with changing ecosystem and think beyond the possible. What is the biggest challenge in doing this? "Unlearning and Learning", we think the current ecosystem is the best. Be it health, finserve, agriculture or mechanical domain, we need to emphasize with the stakeholders, to come up with the strategy to drive. The very evident example here is the quality of life is changing every millisecond. Few decades back the phone connection was limited to few, but today all the millennials are having a mobile phone. Now phone is not just a medium to talk, but are so powerful devices that an innovative solution can be developed on it.
Learn Git in a Month of Lunches
Hello Everyone,
Outstanding Outlier: “AG”
Learn Git in a Month of Lunches
Hello Everyone,
IT industry is going through a disruptive evolution
where being AGILE and adopting DevOps is the key catalytic agent for
accelerating the floor for success. As explained in my earlier blog, they complement
each other rather than competing against one another. If Leaders will at the
crossroad where in case they need to pick one what should be their pick. There
is no right or wrong approaching, it depends on the scenario and dynamics for
the program or project. I would personally pick #DevOps over Agile as its supremacy
lies in ACCELERATING delivery with RELIABILITY and CONSISTENCY.
This path will enable and empower development teams to be more productive and
prone to less rework. Does this mean adopting DevOps with any standard will
help reap benefits? In this blog, I will focus on importance of one of the
standard and best practice around Code branching and merging strategy to get the
desired outcome by adopting DevOps. To drive Delivery in much more efficient
and eloquent way, everyone should adopt best practices to sustain in the
current competitive ecosystem, by keeping cost to minimal. What I am going to
cover in this blog are few best Code Branching and Merging (CB&M) trends
however they should be fine-tuned depends on the project dynamics.
DevOps spread is across all phases and not limited
to Build, Test or Deployment phases alone.
Before build phase, DevOps architect should lay down the protocol and
clear guidelines how team members during build phase will approach for CB&M.
Code Branching enable team to work in parallel whereas Code Merging help teams avoid
stepping on each other shoes and enable avoid rework by arresting code
override. CB&M strategy should be agnostic to the tool and technology be it
TFS, GitHub, CVS or Team forge.
Typical challenges because of lack of proper CB&M
strategy:
- Code Merge miseries and mysteries of who override the code.
- Fear of Rewrite because of override.
- Delayed release because of Branch and Merge overheads.
- Quality issues because of improper merging.
- Rework because of deadlock merging.
- Last minute production delays because of wrong code merge and semantic conflict.
- Production branch need to have latest and greatest code, matches production version.
I recall few mitigations we use to define. These
mitigations with be a history only with well-defined CB&M strategy.
- Dedicated code manager to create branches and sync up with master branch.
- Merging frequently and smaller rather than rarely and large.
- Rebuild code multiple times in a day to ensure no override.
- Multiple roots to address multiple versions of code.
Moreover, during the journey for each release, we found
that our deployment scripts were unverifiable and unreliable to get latest code
at any point in time for redeployment. Post code branching and merging mess up
it become an endless loop, means as one issue gets uncovered it typically
unveil another hidden issue. All this led to delays and infuriating situations
when discussion become tense and unmanageable.
Not merge changes
into the production line until feature line is feature ready, is called cherry-picking;
where teams decide which features to merge in before release.
Here are few best practices to manage Code
Branching and Merging strategies:
Define
source control FOLDER correctly.
- Trunk-Based Development (TBD), where all developers commit to one shared branch. Release manager, picks up the committed code from individual developer and finally based on assessment go for final commit on Trunk. Not a good practice for enterprise wide single big release.
- Branch levels, Here are various patterns defined to handle Branching and Merging issues. Centralized Master Branch (Production equivalent).
Define appropriate
Tagging. Tagging help fetch source code based on logically segregation.
- Daily Tagging
- Logical Feature based tagging.
- Product level Tagging.
- Production level Tagging.
Define
Merging strategy. "Merging" is the act of integration into your
current working branch from another branch.
- Fast forward Merge. Keep moving and as logical commit happen on one branch, merge into working base branch.
- Rebase with every commit and merge. Every commit by developer merges back to the base and it will be categorized as rebase.
- Avoid last minute merge, without approval from product owner, Scrum master and lead.
- Reverse integration, this approach allows team to merge from the development branch to the main branch. This is more apt for scenarios where logical completion of feature milestone is done.
- Forward integration, this approach allows team to merge from the main branch to a development branch. This is recommended when a child branch is ready to accept the latest code back into its branch from parent branch. Frequent forward integrations into development branches are a best practice.
- Promiscuous Integration, here constant merging between 2 feature lines in play but merge with mainline after completion or big bang merge.
Upfront
capture dependencies.
Frequency
and discipline of merging code
- All developers to merge at least daily
- Every developer is given a slot to merge hence higher the frequency of merge better it is to manage.
- Daily merge call or call out.
- Call it a scrum merge.
- Developers call out before merge to mainline stream and in case of no conflict of interest, auto merge.
- Real time merge using CI. Build Virtual environment for each developer with CI delivery pipeline for individual. Go for Gated check-in to avoid last minute rush. It should cover Code Review, Unit testing and Code build checks.
- Big Bang Merge, merge source code between 2 feature lines constantly but merge with production line after full release is ready to deploy.
After defined bundle of best practices, there is a
high probability of making successful Code Merge and Branching strategy. Best
Practice help get better probability but does not guaranteed error free and
challenge free development journey.
Here are few branching and Merging models.
Branch by Features
- Works well when we have well defined independent scope for each
feature or Release. More so for Kanban it
is great.
Branching for single sprints team.
Branching for Multiple sprints teams.
Branching for Multiple sprints teams with Hotfix branch.
It is important for projects to define and
laydown Code Branch and Merge strategy so control delivery risks and issues and
execute project in controlled manner. With the rise of Distributed Version
Control Systems (DVCS) such as Git and Mercurial, it is easy to layout CI
approach. To ensure things will work properly, they can run builds and tests on
individual branch and later commit to the main branch. Feature toggle and
Branch Abstraction help make sure features are switched “On” or “Off” despite
being half cooked without impacting production line. Pick appropriate Version
Control System or tool which aligns with you CB and M strategy, personally I
prefer GIT for various reason. GIT is the source code management system that
help manage different version of code in parallel without conflict. It emphasis
on Data consistency and Integrity, Distributed environment. It helps keep
version of code. Occasionally while working on a project one would like to go
back to previous version to validate or modify or confirm changes. Git is a
very popular open source, code versioning tool that will help one mange
Versions of Configurable Items and Artifacts, based on merge strategy. Merge
strategy is key for DevOps projects as that will form the base and first step
for DevOps.
I
hope this blog was helpful and enabled teams to work in parallel yet have
proper strategy for Code Branching and Merging. It is an important change for
people to stay connected while doing development and yet work independently
without overriding each other’s code. Happy Coding Branching and Merging.
Outstanding Outlier: “AG”
Comments
Post a Comment