Ok, I think the summary didn’t have the intended effect. I see we’re not all on the same page That’s totally fine. Let’s see if we can align all our ideas and definitions around feature toggles while not making this a wall of text.
EDIT OMG this is huge… shall we change the format of this discussion? I’d be very hard for me to read something like this…
First of all, I want to highlight this only applies in the very few cases were we will use a feature toggle. I don’t want anyone to think now everything will come hidden in a toggle and we’ll change all our delivery process.
Who is in charge of what
To answer you @Rachel
- Release happens and I’m assuming only super admin get their toggle activated.
We started enabling customer balance to super admins because it’s the simplest way to get someone to use customer balance and gather production metrics while not revealing the change to regular users. It doesn’t mean it should always be like this. To me, this is a case per case decision to be taken at production curation, led by the PO and tech lead.
Then what happens? It’s the responsibility of the instance manager and support team to test the feature and then decide for which users to turn it on?
Nope, it’s still the responsibility of the core team, particularly PO and tech lead, to test the feature in production. That is, to gather feedback from users, feedback from instance managers, check performance metrics, etc. Then, it’s still the responsibility of the core team to decide how to proceed with the roll-out based on this feedback.
Do we really have the problem?
yes, I’ve watched the pipe closely and PRs tend to pile up in Test Ready (we can check Github’s even feed in the PRs themselves). I believe manual testing is one of the causes but not only.
And if so, isn’t the bottleneck just moved on to production (ie on to support team)?
We might still need to work on the deployed change to actually release it to customers (it’s still disabled for all users) but it’s not blocking the pipe: the code got merged to
master which means that said PR won’t diverge from the rest of the codebase, it won’t need merge-conflict resolution, we know up until this point things are working and risks are also more manageable because smaller PR get shipped.
I think this definition is misleading the conversation. Toggles do not make the delivery cycle shorter.
yes, they do, because of what I mentioned above. Smaller changesets make it faster to
master because their risk is smaller, they are also way quicker to review, and so they make it faster to production.
They can make merging happen faster. But delivering to all users will still take as much time as before…
I agree. We add steps that didn’t exist in the process, however, my hypothesis is that, due to the feedback-loop, at the point of delivering to all users, the team will be fully confident that what’s delivered solves users’ needs and with increased quality. I think that dividing the development into smaller chunks and acting upon this early feedback will shorten the time it takes to have a new feature available to all users and stable (no known bugs or edge cases). The earlier we catch defects, the cheaper they are to fix (this statement is not mine; it’s popular wisdom). It’s like we can adjust more often, and before it’s too late although there’s no magic. We’re still a small team.
Can you explain how and why?
yes, the small granularity level of a PR is no longer the smallest change that can be understood by and look consistent to users. We can go beyond that and ship bits of frontend stuff without any backend ready yet like we’ve been doing with unit prices.
Also, I think about customer balance. The goal in the first place was to be able to fix the performance hit while also fix the calculation everywhere in the app. Unthinkable to open a PR fixing it all in one shot. No one would review it.