Building SKY UX
- Thursday, January 7, 2016
As the SKY UX codebase is now officially Open Source and in a public GitHub repository, I wanted to walk through what a typical contribution and release look like.
This is meant to be a fairly high-level overview. The example workflow shown on the Travis CI homepage is almost identical to our implementation, aside from the deployment endpoint used. It still makes for a nice visual representation of our processes.
Example contributing workflow
Example releasing workflow
The steps necessary to clone and contribute to the SKY UX repo are already documented in the README. Assuming you follow those instructions, once you submit a pull request against the master branch, GitHub webhooks trigger the following services to run in parallel.
CLA Assistant checks to see if all contributors in the pull request have signed the Blackbaud CLA. If not, they are emailed with a direct link to sign and the pull request is flagged accordingly.
Code coverage results are sent to Coveralls.io, which in turn updates the status of the pull request. Based on our settings, we require 100% code coverage. Anything below this will cause the pull request to fail.
Thanks to the robust Travis CI platform, we're able to use the same tools and workflow to perform releases. The contributing criteria must first be met. If those steps pass, Travis CI checks the commit for two additional criteria - branch name and commit message syntax.
The resulting build files are first committed back to the repository int he same branch (master or rc-) that initiated the release. They're committed with a specific commit message that causes Travis to ignore it.
The build files are also committed to the releases repository. This repo is directly tied to an Azure Website, which ultimately serves as the origin to the SKY UX CDN. This update is automated and driven by Stache.
Last, as long as it's not a pre-release, the documentation site is updated. This is controlled via the skyux-docs repository. Just as with releases, an update to the docs repo will cause an Azure Website to automatically regenerate, also utilizing Stache.
With every service and toolset described above, there is undoubtably an alternative. All software development is subject to change, but front-end development seems especially susceptible to this. Each solution has their own strengths. At the time of implementation, we evaluated our options, and made a selection - aiming for the right tool for the job.
Stay tuned for future posts on deeper dives into some of the more intricate areas of our development cycle, such as our testing strategy.