What are these texts?
I was studing and for me to have some real study done I need to write it down, this is a small collection of topics that I studied in the last few weeks.
Other links from the same study-pool:
What is a release strategy?
Release is when the software is ready to be pushed to production. The process can also involves making the software open to a small group of users.
What kind of releases we can use?
Continuous release availability
Delivery teams can release their solutions whenever they want. This is the only strategy that supports continuous delivery. To make it work, a host of practices are required, such as fully automated deployment, fully automated regression testing, feature toggles, self-recovering components, and many others.
Release windows
A release window is a period of time when one or more teams can release into production. A release slot is a subset of the release window during which a team can deploy their solution into production. If your organization has a policy that production releases occur between 1 am and 5 am on Saturday nights, then up to four releases may occur during that window.
The advantages of this approach are that it provides a consistent release schedule to business stakeholders and that it has release date targets for delivery teams. Slow cadence release windows can be a problem for release management processes that need to support multiple teams. Teams have to aim for a future release window because there are only so many release slots available during each window. This problem gets worse when teams move to a continuous delivery strategy.
Release train
The idea of a release train is that every team involved with that train has the same release schedule, for example, this train releases once a quarter, or once a month, or even once a week. In large programs, where the individual teams are each working on part of a larger whole, this strategy is used.
A release train provides a consistent release schedule for stakeholders and serves as a rallying point for development teams. The train metaphor works well in practice. If your team misses the release date, the train goes on without you, and you need to wait for space on the next train.
Dependencies are also respected. Similar to a family taking a trip together, if several components need to ship together they have to go on the same train. Development teams are constrained to a common release schedule, making it difficult to support lean or continuous delivery strategies. Slow cadence release windows can cause a potential disadvantage, as release trains may also suffer from them.
Ring deployment
Different groups receive a new feature to manage the risk of deployment. These groups are represented as a series of rings, starting with a small group and growing to encompass all your users.
Pick users for each group based on similar attributes or an opt-in process if you do a ring deployment. Features can be made available to those groups. It is possible to release to internal users first, then to the other users, and then to all users.
Percentage-based releases
In a percentage roll out, the deployment has already happened and the release will be based on a percentage. The new feature will be rolled out to 10% of users, 25%, then 50%, until all users receive it. Users are randomly selected to get the new feature. If there is a way to identify them, they retain access to the new feature. When users must log in to use your product or accept cookies, this is the best kind of sorting.
There is little variation in your targeted user base, so these releases are useful when you cannot run a beta program. If you run a small B2B application with the same 1000 monthly active users, a percentage-based release is likely to give you an accurate estimate of whether the full rollout is likely to have a positive or negative impact on your user base.
Canary releases
A canary release is a test to see if a feature release will have a positive impact on users. Only a small number of your users will be able to use the new feature, and you can only target them based on who they are.
Make sure the small group in your canary release is representative of your overall users. Older versions of a phone's operating system may be missed if a canary release only goes to people with the latest phones.
A canary release can be used to test capacity management and user acceptance. If you roll out a new feature to a group and realize that it consumes too many resources, you can turn the feature off and make the product better.
Targeted releases
It makes sense to target a release based on something other than percentages. A food delivery service could try out a new feature or set of related features in one medium-size city to see how it works for multiple types of users.
If that service makes a change that affects restaurants, drivers, and consumers, all of those users should receive the change at the same time. If the city-wide roll out produces good results, the service can release it to the rest of their user base.
Entitlement releases
It's possible that you want a flag that affects access. What users can do on your platform is affected by these flags. An entitlement release can be used to add a feature that is only for a small group of users. If you had a premium service, you could change the release to only allow people who paid a membership fee to use it.
You can combine entitlement releases with percentage-based releases or canary releases, but only some users will have access to the feature after the release is done.
Post-release tasks
When the feature is fully deployed, your flag's lifecycle doesn't finish. You need to have metrics and monitoring set up to view human and system behaviors, and you need to have a plan to remove temporary flags after you fully implement the new feature.
Tracking metrics.
We can determine whether something is improving or not by using metrics. When releasing new features, you should consider what metrics you need to track.
With the deployment of a new feature, the availability, reliability, and response time of the application should not change. Before, during, and after you deploy code, set up monitoring to make sure it doesn't degrade.
Depending on your objectives and business, the metrics you track will be different. Tracking metrics such as page load time, errors, uptime, conversions, or user registration can tell you whether a feature is performing well or causing problems.
The flags are being removed.
It is not a good idea to include deployment and release flags in your code. After a feature is stable and fully released, you can remove the code associated with the feature flags. It eliminates the chance of accidental deactivation of the feature and makes your code easier to read and understand.
Top comments (0)