Intermediate
Intermediate
The release train branching strategy is similar to what is sometimes referred to as late branching or trunk based development. Essentially it implies that in your entire branch tree there is only one branch that is meant to be long-lived.
Consequently, there is only one way you can contribute to a product and have your code released, and that is to deliver your code to the mainline.
In a release train strategy, the mainline is on itās way to production all the time, and therefore anything that isnāt meant for production as soon as possible, shouldnāt be delivered to the mainline.
Whenever you ship a new release you probably need a release note, a report listing the new version number, fixed issues, new featuresā¦
Why write all that manually? By building up your traces and recording your trails as you work, you can pull all this information out of your backend automatically.
Youāve written your last release note. From here on out itās release notes as code.
Management and maintenance of your test data is considered part of your Quality Assurance strategy. Your test data is versioned and stored as an artifact.
This implies that you separate your test data from the actual tests, which in turn comes with the benefit of easily running test suites with different, versioned data sets.
Test suites becomes self-contained, each with their own easy reproducible setup and tear-down steps, something that will later enable you to run your test suites independently of each other - maybe even selected on output from previous verification steps in your pipeline.
All software has dependencies; You may be using third party technology or you have a lot of individually released microservices, frameworks or libraries in your system architecture.
Make sure there are no moving targets and donāt rely on someone elseās master, latest or stable release. Cache everything you need in your own registry.
Optimize your link processes to use cached dependencies when available, optimize your compile processes to feed the registry when new versions are created, so others can benefit from them.
Both successful deployment and functional testing are often considered part of the definition of done.
When weĀ“re building continuous delivery pipelines itās because we want our developers to have access to, and to execute, the full definition of done.
Use simulators, emulators, containers and VMs to verify your definition of done and ensure stable releases. The closer to production your testing environment, the more confidence you can have in your changes.
Assignments should be prepared for working before they qualify as actual tasks. The goal of a task must be known to the person who is implementing it.
If a task is ambiguous it can not be estimated, and if it can not be estimated, it can not be prioritized.
If a task doesnāt have a clear definition of done, then it should be time-boxed.