Migration checklist

[bridgetkromhout]

What we have to do, and when.

Preparation

• heads-up to core org team
• establish a timeline: Create communication with migration information #96 (comment)
• send communication with timeline and link to organizers: Create communication with migration information #96
• add exact replicas of current events' 2016 sites to new repo (this is the main place you can help!): migration for 2016 events #107
• Migrate 2015 and previous: Migrate events from 2015 and before #29
  • Pick & announce date for freeze on merges to webby content 2015 and before: Determine cut-off for read-only sites #95
• [ ] Dump webby one last time & migrate as html
• determine how/if we'll test changes in a shared staging env after cutover
• add needed maintainers to org
• crawl for broken links
• Set date with Patrick for DNS cutover

Cutover time

• Verify that test site looks good
• Patrick to make DNS change to github pages
  • Cloudflare right away? for future SSL?

After cutover

• crawl for broken links
• send communication reminding everyone where to submit PRs now

[mattstratton]

Should you add a step for "post-cutover" to lock down the old repo/remove committers? I suppose if all the committers to the old repo have given a thumbs up that they KNOW to not accept pr's on it, that's fine too.

[bridgetkromhout]

Should you add a step for "post-cutover" to lock down the old repo/remove committers? I suppose if all the committers to the old repo have given a thumbs up that they KNOW to not accept pr's on it, that's fine too.

That will be up to Patrick since he controls the old repo (it's in his personal account and he is thus the only one who can add/remove committers).

Presumably once it controls nothing, PRs to it will just be a no-op.

[jedi4ever]

@bridgetkromhout @mattstratton if you can say how to generate the new static site I can add the build circle.yml to upload it to s3 & map it to the devopsdays.org route53 record

[mattstratton]

@jedi4ever I'm slightly leery about changing the build system off of wercker and gh pages, as it's completely working now. Given the timeframe we are working on, changing the build plumbing on the app makes me nervous. All that is needed for the cutover is cnaming the devopsdays.org route53 record to devopsdays.github.io (when we are ready to go, that is).

[mattstratton]

in theory it should be pretty straightforward though, but since I'll be moving fast with changes and I want to be able to see exactly when they change, etc, during the next couple weeks, i'm nervous about losing that insight.

[jedi4ever]

root records of dns can not be CNAME's - one of the limitations so it would only work with www.devopsdays.org and not devopsdays.org - building it on werker & gh pages is fine . I'll add the push to s3->bucket don't worry. I just need some wercker access to add some private keys

[bridgetkromhout]

Hi, @jedi4ever - @mattstratton can set you up with any access you need.

I'd like to serve the devopsdays.org site from github pages and build with wercker because it's much easier to federate/distribute access with that. I don't want to involve S3 at all.

I use github pages with bridgetkromhout.com on github pages no problem. Github provides IPs to use for that.

Thanks!

[mattstratton]

@jedi4ever I do this today with www.arresteddevops.com and arresteddevops.com pointing to gh pages. It works fine. I know that technically the RFC says you cannot cname a root record, but every provider does it and it works fine for everyone. :)

[jedi4ever]

got it @bridgetkromhout - E-TOO-OLD-GITHUB-KNOWLEDGE
this is the new way -https://help.github.com/articles/setting-up-an-apex-domain/
let me know when you want/need to switch

[mattstratton]

(basically, it works because cloudflare does cname flattering) https://support.cloudflare.com/hc/en-us/articles/200169056-CNAME-Flattening-RFC-compliant-support-for-CNAME-at-the-root

[mattstratton]

Either way, bikeshed accomplished! Thanks for digging that up!

[jedi4ever]

I've rechecked the config

technically devopsdays.org -> redirects to www.devopsdays.org
and www.devopsdays.org -> fastly -> s3 bucket.

don't think you can browser cache on github pages , let me know if you'd like to use fastly as a CDN

www.devopsdays.org.     289     IN      CNAME   www.devopsdays.org.global.prod.fastly.net.
www.devopsdays.org.global.prod.fastly.net. 19 IN CNAME global-ssl.fastly.net.
global-ssl.fastly.net.  19      IN      CNAME   fallback.global-ssl.fastly.net.
fallback.global-ssl.fastly.net. 19 IN   A       23.235.43.249

[mattstratton]

Yeah, I handle all my speeding up stuff via cloudlflare (injecting browser caching, cdn, etc) so i guess you would just need to reconfigure fastly to point to the gh pages as it's origin. That should work okay since you just have to make sure that GH pages knows the x-orginally-to header for it to serve.