Re: Schedules - breaking it down

Hi Julee, all

I think that working with the most complex issue first is better than estimating without knowing nor touching the complexities. At least for a few hours, it helps estimating.

Now that I did what I just explained, I'll follow what you are suggesting; see  [0]


The idea is that we should have a live environment that Fastly points to (what I generally refer to "Prod" for "Production").

All environments (production, staging, testing, dev) are going to be completely independent, not even in the same cloud provider.

Regarding the switch-flip period. Since fastly allows us to say which nodes are used as backend, flipping from one to the other can be done in seconds. And, sure, we will have a testing environment.

For example, at the moment I built a test host using fastly at [1]. But it is using the same environment, but using a different set of backend servers than the real is using. It is not complete, but at least filled some testing needs. Something that has to change.

All of this is going to be described in [0]

  [0]: http://docs.webplatform.org/wiki/WPD:Infrastructure/analysis/2013-Migrating_to_a_new_cloud_provider
  [1]: http://test.webplatform.org/


Renoir 
~

On 2013-10-25, at 1:25 PM, Julee Burdekin <jburdeki@adobe.com> wrote:

> Hi, Renoir:
> 
> Cool. That's the step Migration, #2, below. So you can start now by estimating the time for each of your bullet points, and how long each subsequent cycle is. Then, when Doug provides you with the hard end-date, you can work back from there. (That'll even give you the date when you need access to the new data center, at which point all the agreements/paperwork should be done.)
> 
> Sounds good?
> 
> (An aside: will you send out a migration plan? We should prepare the community on things like: how dev/testing/staging/prod will work on these 2 instances, will there be down times due to work? If not, how long is the switch-flip period? Will you be asking the community to test it in the wild for a day or so?)
> 
> J
> ----------------------------
> julee@adobe.com
> @adobejulee
> 
> From: Renoir Boulanger <renoir@w3.org>
> Date: Friday, October 25, 2013 6:21 AM
> To: julee <jburdeki@adobe.com>
> Cc: WebPlatform Public List <public-webplatform@w3.org>
> Subject: Re: Schedules - breaking it down
> 
> Hello Julee, all
> 
> I think there are missing points:
> 
> Migration:
> - rework hard coded configuration management script that applies only to current location
> - test in a separate environment the configuration management scripts
> - create two new environments in new cloud provider (test, production)
> - code a synchronization script (files, replace database) to make final migration flip be as quick as possible
> - test whether we can send play log to new production db server deployment
> 
> 
> These steps are roughly what has to be done and should be done more than once to ensure the real flip is seamless.
> 
> 
> Renoir Boulanger | Developer operations engineer
> W3C | webplatform.org
> 
> http://w3.org/people/#renoirb ✪ https://renoirboulanger.com ✪ @renoirb
> ~
> 
> Julee Burdekin <jburdeki@adobe.com> wrote:
> 
> Hi, Doug, Renoir & Alex:
> 
> As we discussed in the last meeting, we need to make sure the various projects are coordinated. So I thought I would share with you what needs to happen to make sure we have rough schedules that we can compare:
> 
> Migration:
> Doug needs to provide the end-date for the HP contract.
> Renoir can then sketch a high-level schedule for migration.
> Compatibility tables:
> Doug needs to follow up with Ronald regarding the Compatibility Tables Phase 1 work: what's the end-date?
> Then, someone needs to estimate the time it'll take the frontend dev person to script parsing the object Ronald comes up with & inserting it into the property pages.
> If the timeline for either of these two items is too lengthly, we should meet to come up with a manual workflow for getting the data into the pages.
> CSS Properties project:
> Julee needs to come up with a new endgame schedule (dependent on the Compat-tables schedule).
> Alex needs to come up with a relative launch schedule.
> I hope this helps breaking it down so we can get these out. If we need swim lane diagrams, I can work them up based on the information you provide. But let's keep them really simple: even just starting out with bullet points might give us a lot of info.
> 
> Regards!
> 
> Julee
> ----------------------------
> julee@adobe.com
> @adobejulee