Skip to content

Instantly share code, notes, and snippets.

@notmessenger
Last active April 27, 2018 17:56
Show Gist options
  • Save notmessenger/5f8041d948b660d045500c0aa7fbaa0c to your computer and use it in GitHub Desktop.
Save notmessenger/5f8041d948b660d045500c0aa7fbaa0c to your computer and use it in GitHub Desktop.
Slides for Frost Foundation presentation
<html>
<head>
<title>Frost Foundation: What it is and how to use it</title>
<script src="https://code.jquery.com/jquery-3.3.1.min.js" integrity="sha256-FgpCb/KJQlLNfOu91ta32o/NMZxltwRo8QtmkMRdAu8=" crossorigin="anonymous"></script>
<style>
.slide {
height: 1500px;
width: 1200px;
}
.slide {
padding-top: 50px;
}
.slide.intro {
padding-top: 100px;
}
.intro h1,
.intro h2,
.intro h4 {
text-align: center;
}
.navigation {
display: flex;
margin-top: 100px;
width: 1200px;
}
.navigation .next,
.navigation .previous {
font-variant: small-caps;
cursor: pointer;
}
.navigation .next {
margin-left: auto;
}
</style>
<script>
function addNavigation() {
const slides = $('.slide')
let slideId = 1
const slidesLength = slides.length
slides.each((index, element) => {
const nextSlideId = slideId + 1
const previousSlideId = slideId - 1
element.id = slideId
const previous = document.createElement('div')
previous.className = 'previous'
previous.onclick = function() {
goToSlide(previousSlideId)
}
previous.appendChild(document.createTextNode('previous'))
const next = document.createElement('div')
next.className = 'next'
next.onclick = function() {
goToSlide(nextSlideId)
}
next.appendChild(document.createTextNode('next'))
const navigation = document.createElement('div')
navigation.className = 'navigation'
if (slideId > 1) {
navigation.append(previous)
}
if (slideId !== slidesLength) {
navigation.append(next)
}
element.append(navigation)
slideId++
})
}
function goToSlide(id) {
window.location.href = `#${id}`
}
$(function() {
addNavigation()
})
</script>
</head>
<body>
<div class="slide intro">
<h1>Frost Foundation</h1>
<h2>What it is and how to use it</h2>
<h4>Slides - <a href="https://bit.ly/2r63uV5">https://bit.ly/2r63uV5</a></h4>
</div>
<div class="slide">
<h1>Problem</h1>
<h3>Dependency Management</h3>
<ul>
<li>We have a large number of Ember CLI addons, many of them with inter-dependencies on each other.</li>
<li>These all had different versions they relied on amongst themselves resulting in no guarantee of which version would actually be used by an application.</li>
</ul>
<h3>Compatibility amongst addons</h3>
<ul>
<li>It is often difficult to know which versions of which addons are compatible with one another (consumption inside another, APIs, etc).</li>
<li>These addons often have compatibility issues as well between the versions of Ember CLI being used by them and your application.</li>
</ul>
</div>
<div class="slide">
<h1>Solution</h1>
<h3>Frost Foundation</h3>
<ul>
<li><a href="https://github.cyanoptics.com/Frost/frost-foundation">https://github.cyanoptics.com/Frost/frost-foundation</a></li>
<li><a href="https://github.cyanoptics.com/Frost/frost-foundation/blob/master/MIGRATION_GUIDES/1.0.0.md">https://github.cyanoptics.com/Frost/frost-foundation/blob/master/MIGRATION_GUIDES/1.0.0.md</a></li>
<li><a href="https://confluence.ciena.com/display/frost/Upgrading+Applications+from+Ember+CLI+2.8+to+2.12.3">https://confluence.ciena.com/display/frost/Upgrading+Applications+from+Ember+CLI+2.8+to+2.12.3</a></li>
</ul>
</div>
<div class="slide">
<h1>Applications, not Addons</h1>
<ul>
<li>Frost Foundation is designed to be installed in Applications, not Addons</li>
<li>It is unlikely that there will be a version targeting Addons because it's a different type of problem.</li>
<li>Will touch on this again in the Tooling conversation</li>
</ul>
</div>
<div class="slide">
<h1>Frost Foundation is the embodiment of the effort it took to solve these problems</h1>
<h2>But there's additional continual effort required of everyone</h2>
<ul>
<li>The Frost Foundation package has only solved this problem for the 43 repositories that are under the direct purview of the UI Platform team
<ul>
<li><a href="https://confluence.ciena.com/display/frost/Frost+Foundation+Ecosystem">https://confluence.ciena.com/display/frost/Frost+Foundation+Ecosystem</a></li>
</ul>
</li>
<li>There are dozens more addons within the Ciena organization that need to use the same compatible versions of dependencies
<ul>
<li>Please start sending me links to all of these repos</li>
</ul>
</li>
<li>There are also various applications within the Ciena organization that need to use the same compatible versions of dependencies
<ul>
<li>Please start sending me links to all of these repos</li>
</ul>
</li>
<li>MAJOR releases of addons have a cascading upgrade effect that needs to be managed</li>
</ul>
<h3>How?</h3>
<ul>
<li>Upgrade your applications to begin using Frost Foundation</li>
<li>Upgrade your addons to use the same dependencies compatible with Frost Foundation</li>
<li>Continue to remain aligned with Frost Foundation
<ul>
<li><a href="https://confluence.ciena.com/display/frost/Changes+to+Ember+Addons+and+Apps">https://confluence.ciena.com/display/frost/Changes+to+Ember+Addons+and+Apps</a></li>
<li>#frost-foundation Slack Channel</li>
</ul>
</li>
</ul>
<img src="https://user-images.githubusercontent.com/435544/37919606-0125f1ec-30ea-11e8-9f9e-28f9cddc79fe.png">
</div>
<div class="slide">
<h1>Release cycle</h1>
<ul>
<li>There is not yet a defined release cycle.</li>
<li>General idea is that MAJOR changes of addons will get queued up and a new MAJOR of Frost Foundation will be released.</li>
<li>As we adopt Frost Foundation patterns will begin to emerge</li>
<li>As we are able to upgrade to newer versions of Ember CLI additional patterns will emerge</li>
<li>Items in the "Future" section later will affect patterns and abilities"</li>
</ul>
</div>
<div class="slide">
<h1>More about the overall effort</h1>
All Frost Foundation repositories:
<ul>
<li>have had GitHub Issue templates added to them
<ul>
<li><a href="https://github.com/ciena-blueplanet/ciena-devops/blob/master/.github/ISSUE_TEMPLATE.md">https://github.com/ciena-blueplanet/ciena-devops/blob/master/.github/ISSUE_TEMPLATE.md</a></li>
<li>FEATURE REQUESTS should be created and then discussion should ensure before a PR is submitted
<ul>
<li>is best practice</li>
<li>prevents having to release MAJOR to address API deficiency in MINOR</li>
</ul>
</li>
</ul>
</li>
<li>have had GitHub Pull Request templates added to them
<ul>
<li><a href="https://github.com/ciena-blueplanet/ciena-devops/blob/master/.github/PULL_REQUEST_TEMPLATE.md">https://github.com/ciena-blueplanet/ciena-devops/blob/master/.github/PULL_REQUEST_TEMPLATE.md</a></li>
</ul>
</li>
<li>now use Node 8.1.2 or 8.6.0, which provides NPM version 5</li>
<li>use the latest version of pr-bumper</li>
<li>employ the protected branch and CODEOWNERS capabilities of GitHub to:
<ul>
<li>remove the usage of Pull Approve</li>
<li>require a build to pass before a PR can be merged</li>
<li>require a code review before a PR can be merged</li>
<li>require architecture-related files be reviewed if changed in a PR</li>
</ul>
</li>
</ul>
To facilitate this:
<ul>
<li>all Frost Foundation repositories on Bitbucket have been moved to GitHub Enterprise.
<ul>
<li><a href="https://confluence.ciena.com/display/frost/Move+Bitbucket+Repository+to+Github+Enterprise">https://confluence.ciena.com/display/frost/Move+Bitbucket+Repository+to+Github+Enterprise</a></li>
<li><a href="https://confluence.ciena.com/display/frost/Create+a+new+Github+Enterprise+repository">https://confluence.ciena.com/display/frost/Create+a+new+Github+Enterprise+repository</a></li>
</ul>
</li>
<li>GitHub Enterprise is being upgraded to the latest version
<ul>
<li>Until then PRs will not be blocked for code review so need to be very diligent about following the process for the repos
<ul>
<li>ciena-coment</li>
<li>ciena-icons</li>
</ul>
</li>
</ul>
</li>
</ul>
</div>
<div class="slide">
<h1>Tooling</h1>
<p>Some already have, some are achievable in the near-term, and others are future plans</p>
<p>Frost Foundation (and compliance)</p>
<ul>
<li>Manage MAJOR releases</li>
<li>Audit apps and repos for compliance</li>
<li>Dashboard</li>
<li>Open PRs to align with compliance</li>
</ul>
<p>Pull Requests</p>
<ul>
<li>Build a demo app for each PR accessible at a url</li>
</ul>
</div>
<div class="slide">
<h1>So what does the future look like?</h1>
<ul>
<li>We just talked a little bit about it in the previous Tooling section</li>
<li>Workspaces in both NPM and Yarn, with Ember CLI support</li>
</ul>
</div>
<div class="slide">
<h1>Questions?</h1>
<p>And then there's one more slide</p>
</div>
<div class="slide">
<h1>Repository Champions</h1>
<p>What do we think of this idea?</p>
<ul>
<li>We have a large pool of UI developers in the organization, not just Hoth team members</li>
<li>1 (or 2) of these developers are designated as the champion for a repository
<ul>
<li>become primary contact point for FEATURE REQUESTS</li>
<li>responsible for alignment of architecture, direction, etc with larger vision/efforts</li>
<li>coordinate activities with other champions and UI Platform (Architecture) team</li>
<li>jointly responsible with rest of team for PR reviews and approval, though have final say</li>
</ul>
</li>
<li>1 to 3 other developers are assigned to the same team
<ul>
<li>in order to learn</li>
<li>in order to assist</li>
<li>jointly responsible with rest of team for PR reviews and approval</li>
</ul>
</li>
<li>A Champion will be assigned as a non-champion to another repository</li>
<li>A developer should not serve as a Champion for more than 2, maybe 3 repositories</li>
</ul>
<p>This helps keep everyone informed</p>
<p>It spreads out the requirement of select developers having intimate knowledge of every addon</p>
</div>
</body>
</html>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment