-
Notifications
You must be signed in to change notification settings - Fork 903
Q4 2016 Roadmap
The ngUpgrade story was a bit of a disaster, but we're finding React pretty nice to work with, and the migration to React is going faster and easier than any of us expected! So...Goal #1 is out. Goal #2 is still in the works for this quarter. Goal #3 is in progress, and we're hoping to have something in place by the end of the quarter.
As Deck, the Spinnaker UI, continues to grow and evolve, so do the web frameworks and libraries it’s built upon. When we started writing Deck in 2014, AngularJS was still in version 1.2 and Angular 2 had not even been announced. Grunt was the de facto build tool. Coffeescript was still popular.
In the two years since those first commits, the Javascript landscape has changed tremendously. ES2015 has introduced a ton of exciting language features (classes, arrow functions, object destructuring, default parameters, etc.) that make programming for the browser easier and more concise. Build tooling has evolved (gulp, browserify, webpack, rollup). Typescript has grown up and is now in its 2.0 release. And Angular has been completely rewritten.
We’ve tried to keep up. We’ve followed Angular 1.x from 1.2 to 1.3, 1.3 to 1.4, 1.4 to 1.5. We moved our build from grunt to gulp, then to browserify, then to webpack a year ago (thanks to Zan Thrash and Ben Malley). We brought in Babel to let us use many of those ES2015 features.
We’ve watched Angular 2 shape up to become the framework that was officially released in September. And we’re excited about it. It improves upon many of Angular 1’s shortcomings, it’s much more performant, and it encourages cleaner, more modular code. There are a ton of benefits to using Angular 2, and now that it’s out of its RC release cycle, we’re looking at it seriously.
During the first year of Deck’s development, there were really just two teams involved: the core team at Netflix, and one or two people at Google. We were able to iterate quickly, and communication was easy - there were rarely more than three people actively working in the codebase. We were able to design decent pluggable modules for things like cloud providers, notification types, pipeline stages and triggers, and other features. Because Netflix has different needs and customizations than most users, we found ways to customize the UI and plug in custom components and views. It hasn’t been perfect, and there’s still a lot of duplicate code, but it’s a pretty good system, and we’ve seen teams validate our abstractions: Microsoft (for Azure), Pivotal (for Cloud Foundry), Target and Veritas (Openstack), Google (Kubernetes), even internally at Netflix (Titus). We’ve gotten great contributions from folks at BMC, Full Contact, and other organizations. Over 50 people have contributed to the codebase, and 20 of them have made 10+ commits.
We’re planning on making some big changes over the next few months, and want to share our roadmap for those changes. Considering the number of people involved now, big changes are not so easy. There are ~130,000 lines of code in Deck. That is… a lot of code.
One of our primary goals with all of these changes is to ensure there’s as little friction as possible in the development process, and that existing code just works - or, if changes are needed, they’re minor, and they’re applied across the codebase to existing provider modules.
Angular 2 offers a migration path via the ngUpgrade module. This allows an existing Angular 1 application to run and use Angular 2 modules. Our initial efforts to use it, however, have uncovered some significant issues, mostly around unit testing.
At this point, we’re reluctantly holding off on the migration and will see how that story evolves. What we are doing is starting to adopt Typescript. Writing Angular 1 components in Typescript results in components that look more like Angular 2 components, and our hope is that a future migration is more straightforward.
We already have a style guide, but it’s not well known or maintained. We’re going to update it to include canonical examples from the existing codebase to use as references for new development. We’ll expand the README to describe the style guide further and point folks to it.
The current release approach is rooted in our history as Java development team. Deck is published as a WebJar, which is then unpacked into Apache’s htdocs directory and served as static files. This works, but it’s not ideal - it means all the cloud providers (and all the Netflix customizations) get loaded into the browser at runtime, and features are enabled or disabled via the settings.js file.
We want to publish distinct artifacts to NPM: one for the core module, and one for each cloud provider. And we want to follow semantic versioning - at least for the core module.
We also don’t want this to be a painful process, so we’ll be dogfooding it at Netflix until we’re sure we’ve got it right. During that time, the only real change will be that we’re publishing both a WebJar and artifacts to NPM, and we’ll move the Netflix module out of the repository.
Once we’re comfortable with this, we’ll work with the community to figure out a better build and release process, so folks using just one provider can easily create a smaller application, and can customize the behavior of the application by adding custom stages, triggers, styles, templates, etc.
We’re currently working on some proof-of-concept codebases using Angular 1 and Webpack to figure out good ways to generate and consume custom libraries. Once we’re happy with this, we’ll likely start on the work outlined above.