Talk:Readers/Web/Team/Pushing production code from beta to stable

Jump to navigation Jump to search

About this board

Phuedx (WMF) (talkcontribs)

"The Product manager, Quality assurance (if available) and designer should be engaged as soon as a feature is pushed to production. A card should be signed off in the current sprint before the close of play on Wednesday, the day before it rolls out to production for all users."

Shouldn't the task be signed off and moved to Done after the feature has hit production?

Jdlrobson (talkcontribs)

I think some level of sign off should typically happen before this. If it happens before, it feels like we are releasing untested/unverified code to production which is wrong.

My concern is that we should at least be in the process of signing off when something hits production. The binary "ready for sign off" / "done" doesn't lend itself nicely for this (There have been occasions where it's been done to sign off and also verify e.g.

In bugzilla we had a status "Verified" for this purpose. Adding a verified column feels a bit overkill though.

Reply to "Pushing to stable"
Phuedx (WMF) (talkcontribs)

"Retain any old code for at least 2 weeks, to aid any necessary reverts, then remove from the repository."

Should this be in this section? If so, then could you clarify this point?

Reply to "Signing off changes"

Optimise for allowing reverts

Phuedx (WMF) (talkcontribs)

This section should be stronger: all features, regardless of whether they are new or are replaceming existing ones, should be behind feature flags.

A natural consequence of this is that when replacing existing features, we have to keep old modules around until just after the proverbial switch has been flipped at the very least. It's up to the Tech Lead to schedule the tasks to tidy up the modules.

Reply to "Optimise for allowing reverts"
There are no older topics