Over the last six months or so, CodeShip’s front-end team has been investing heavily in performance improvements by migrating more and more of our front-end components to Vue.js, and by improving how those components interact with our back-end.
We’ve deliberately taken an incremental approach with this work. Rather than one single big project, we’ve been incorporating it into all of our work – and all of our in-between work for over half a year now — and it’s paying huge dividends.
We just finished up one of our favorite things to do – a self-directed sprint of work where our engineers take on any small tasks they’re passionate about. We wrote a bit about that recently if you’re interested in learning more.
One of our front-end engineers spent her time during that sprint expanding our Vue coverage to our teams page, and we wanted to use that as an opportunity to talk about this work in more detail. [Tweet “Continuous improvement is the key for @CodeShip performance using #vue.js writes @ethangj”]
What is Vue?
As Roman says in his blog post, we selected Vue because of its performance, how easy it is to introduce into exiting projects and because of the accessibility of the code itself.
With the decision made, we set out to begin implementation. So far, that has meant more than 30 pull requests with Vue updates over six months, as part of at least five different feature sprints.
And that work continues. What we’ve learned by taking it step-by-step is now being fed directly into new projects as we rewrite things like log handling and interactions between our build systems and our front-end application.
As the work continued, we’ve seen huge dividends, and most likely you have as well too. For example, our recent changes to our team pages cut the page load time down by 60% — and that’s one of the smaller components we’ve refactored!
Webpack beats asset pipeline
We ended up creating one special pack per application page and the benefits have been clear on both the user-facing and internal sides.
Pages driven by Vue apps
We can also leverage feature flagging on the server-side and load a completely different user experience for users without having code bleeding over inside existing experiences. This type of isolation makes ongoing migration to new code paths, like the one we’re discussing here, much easier to roll-out and clean-up.
Now we are able to prototype new apps in isolation at a very fast pace while still following CI best practices. We are sure we will not break the user experience for those who are not running the new application code and will keep an eye on things as we expand the roll-out.
Conclusion and ongoing work
Even though this is only a small summary of the work we’ve done, we hope it’s helped to make more clear the investments we’re making to deliver a better CloudBees CodeShip product – and inform you of what we learn as we do so!
We’re big believers in the idea of “continuous” around here (always keep shipping!), so we’ll keep you updated as we continue to learn from this ongoing, iterative project. It doesn’t have a completion date, as improving performance and making our code smarter and more accessible is a permanent goal of ours.
If you have any questions, don’t hesitate to reach out and ask. [Tweet “Practice what you preach. Read how @CodeShip uses #ci/cd in its own development @ethangj”]