Page MenuHomePhabricator

Implement "new weekly release deploy duration" KPI
Open, LowPublic

Description

Definition: The time to fully sync out a new release from beginning (branch cut) to end. IOW: The process where we take what is in master for MW Core and extensions, make a release of that, and push it out to the testwikis. Time from saying "OK, gotime" to Special:Version showing the update.

Goal: TBD

Purpose: reducing the time to push out new releases means we can push out new/bug fix releases more often

INFO: Separate out into buckets the full scap from other sync-* or non-l10n scap deploys.

Event Timeline

greg claimed this task.
greg removed greg as the assignee of this task.
greg raised the priority of this task from to High.
greg updated the task description. (Show Details)
greg added a project: Release-Engineering-Team.
greg set Security to None.
greg added subscribers: greg, Aklapper, mmodell.
greg renamed this task from Implement "scap duration" KPI to Implement "new branch deploy duration" KPI.Aug 11 2015, 9:58 PM
greg moved this task from INBOX to Backlog (ARCHIVED) on the Release-Engineering-Team board.
greg updated the task description. (Show Details)

what about branch creation? That currently takes a long time.

Also, I don't want to continue creating new branches forever. I still feel very strongly that we should be merging into deployed branches instead of cutting new ones.

what about branch creation? That currently takes a long time.

Also, I don't want to continue creating new branches forever. I still feel very strongly that we should be merging into deployed branches instead of cutting new ones.

Well, that'd be an easy win to cut down the time, eh? ;)

greg renamed this task from Implement "new branch deploy duration" KPI to Implement "new weekly release deploy duration" KPI.Aug 13 2015, 8:04 PM
greg updated the task description. (Show Details)

scap already logs start and end times for a full scap

We should add in all the time that everything on https://wikitech.wikimedia.org/wiki/Heterogeneous_deployment/Train_deploys takes as well.

greg lowered the priority of this task from High to Low.Aug 27 2015, 4:01 PM

Honestly the goal of 20 minutes seems extremely unrealistic. I can't see it ever being much less than 30 minutes of deployment and nearly 60 minutes to branch everything.

Do we have a time based breakdown of a typical deployment?

I am not sure why it takes an hour to do the branching, seems there is still a bunch of manual tasks involved.

Let's not worry about the actual numbers until we get the data :) But I think this speaks to why we want the time broken out by steps.

I can't currently run the branching script on tin because tin is so horribly outdated. :(

And I don't think I can write to logstash / graphite from my laptop. I'm going to create a new instance in deployment-prep for the purpose of making the branch, it's the only way I can think of to get it done since tin will probably never get upgraded.

@Krenair: Everything. But specifically, PHP and Python.

Well, what versions do you need? tin has PHP 5.3 and Python 2.7.3/3.2.3, but mira has HHVM and Python 2.7.6/3.4.0.

That's not a bad idea, if that gives you sufficiently up-to-date software, @mmodell. Either do all the prep work on mira then cp over to tin, or do it all from mira. It should Just Work(TM) right?

php 5.4 is required for make-wmf-branch, currently. But I want to ditch that script anyway.

python 3.4 would be really nice.