Sergey Protko
Some stuff
Trunk Based
Development
Fallacies of "safe" development
- DevOps*: We don't trust developers, deployment/release should be done by a dedicated team
- QA*: We don't trust developers, untested code should not be in "trunk"
- Developers: We don't trust other teams, they are going to break our staff
* DevOps here represents "someone who runs deployments" and not the culture it is supposed to represent.
*QA (Quality Assurance) here is more Quality Control
Not only simple git conflicts
- Semantic Conflicts
- Conflicts within user flow
- Conflicts within requirements
CI is...
- Everyone merges their work into master daily
- Fix Broken Builds Immediately
- Everyone can see what's happening
- Slicing large work into a bunch of small changes is more work.
- The need to slice work into smaller chunks means unfinished features in trunk
- There's a fear that changes could break production since "story" for related code is not "tested".
Challenges
Try and throw away implementation
How to deal with unfinished work?
- Feature flags/toggles
- Branch by abstraction
In essence, replace VCS branches with conditional branches in the code
if (myNewCoolFeatureEnabled) {
return <MyNewCoolComponent some={props} />
}
Many More
Common mistakes with Feature Flags
- Feature Flag Reuse
- Unclear Feature Flag Names/Description
- Not managing your feature flags
Branch by Abstraction
class MyServiceSwitcher implements MyService
{
public function __construct(
private MyServiceOldImplementation $old,
private MyServiceImplementation $new,
private FeatureFlags $featureFlags
) {}
public function doSomething()
{
$isEnabled = $this->featureFlags->isEnabled('relace_some_service')
if ($isEnabled) {
return $this->new->doSomething();
}
return $this->old->doSomething();
}
}
Replace changes
with add + del operations
Copy of Trunk
By Sergey Protko
