Add continuous deployment

[superstructor]

If we introduce a GIT flow based branching model in combination with #116 and the new GitHub releases API we could have continuous deployment.

With each commit or merge Travis-CI can deploy the artefacts (i.e. Sencha Cmd Package ZIP file) as GitHub releases via the GitHub releases API after a full successfull build and all tests have passed.

commit to feature/x = iterate feature with continuous integration testing. No deployment.

feature/x merged into develop = automatically create a pre-release on successful build + tests (POST to releases with prerelease: true)

develop merged into master = automatically create a stable release on successful build + tests

We could also combine this with deployment of the package ZIP file and generated documentation to the gh-pages branch for the http://deftjs.org website and package repository.

The one big challenge I see with this is the local repository crypto keys required for signing the Package ZIP file releases for the http://packages.deftjs.org/ remote repository. Currently John signs the package with his Sencha Cmd keys for local builds. Any thoughts on how we could solve that ?

Interested in everyones feedback!

@johnyanarella, @brian428, @dongryphon

Thanks

[dongryphon]

The way we manage this for Sencha's signing key is that we use a dedicated build agent (we use Team City, but the concept is pretty common in CI systems) that has the proper keys. Once the PKG file is signed, we copy it and the catalog files to our CDN using a manually run build but that could be automated as well.

[superstructor]

Thanks for the insight Don! Its great feedback to have as we consider how to manage signing the DeftJS Package.

As a open source project it would be awesome if we could manage to find a way to do this on Travis-CI. Since everything is essentially public it creates a key management problem, which is not an issue with Sencha Cmd itself.

It may be that we end up setting up a dedicated build agent on a private server that Travis-CI can interact with during the build. So the continuous integration is publically visible on Travis-CI but the key signing is private.

[dongryphon]

Any ideas on how to handle this in a fully public way? I mean the private key must be put somewhere out of sight...

[superstructor]

Yes you are right there is no way I can think of to do this in a fully public way without exposing the private key. It is essentially a key management problem.

I think we will have to integrate a private cloud server into the build process (such as a VPS or Amazon EC2 instance) that has access to the private keys out of sight to be able to do this properly.

[superstructor]

Travis-CI does after all provide a clean solution to this problem.

"Travis generates a pair of private and public RSA keys which can be used to encrypt information which you will want to put into the .travis.yml file and still keep it private."

This can be exploited to publish our ~/bin/Sencha/Cmd/repo/.sencha/repo/private-key.json file as per this GIST.

Looks like we have everything we need to do signed continuous deployment on Travis-CI :-)

[superstructor]

Plus we should do a spike to try and automate uploading new releases to the Sencha Marketplace as part the continous deployment process.

[johnyanarella]

That's great news re: the Travis-CI RSA keys.

I would much prefer to migrate to git-flow and to automate the deployment of prereleases and releases than to continue to manually manage that process. It would help the project to continue to move forward at a faster pace when I'm bogged down with project work (like I am at the moment).

:thumbsup:

[johnyanarella]

I just tried using karma-sauce-launcher on a different project.

Seems like a perfect match for some of our more detailed needs here:

• leverages our existing Karma test runner configurations,
• integrates with Travis-CI,
• capable of running our tests across a wide range of browsers and platforms,
• produces great status images.

Sauce Labs offers free unlimited minutes accounts for use with Open Source projects. I just created an account for the Deft JS project / team.

BrowserSwarm looked interesting, but it doesn't currently support Mocha. (It uses Sauce under the hood for all the good stuff anyway.) With this particular Karma plug-in we can extend our existing testing solution with just a few blocks of configuration (and publishing the access key as you did for the package signing above).

[superstructor]

Awesome. Thanks for looking into this John.

Is this something we would do as part of the continuous deployment branch or as it's own feature that will enhance the continuous deployment branch when integrated ?

On Tuesday, 3 December 2013, John Yanarella wrote:

I just tried using karma-sauce-launcherhttps://github.com/karma-runner/karma-sauce-launcheron a different project.

Seems like a perfect match for some of our more detailed needs here:

• leverages our existing Karma test runner configurations,
• integrates with Travis-CI,
• capable of running our tests across a wide range of browsers and platforms,
• produces a great status imageshttps://saucelabs.com/docs/status-images .

Sauce Labs offers free unlimited minutes accounts for use with Open Source projects. I just created an account for the Deft JS project / team.

BrowserSwarm looked interesting, but it doesn't currently support Mocha. With this particular Karma plug-in we can extend our existing testing solution with just a few blocks of configuration (and publishing the access key as you did for the package signing above).

— Reply to this email directly or view it on GitHubhttps://github.com/deftjs/DeftJS/issues/117#issuecomment-29637595 .

Isaac Johnston

Chief Technology Officer Joukou

iphone. +64 226 383 792 | email. isaac.johnston@joukou.co | _s_kype. isaac.johnston

This email, and any attachments thereto, is intended only for use by the addressee(s) named herein and may contain legally privileged and/or confidential information. If you are not the intended recipient of this email, you are hereby notified that any dissemination, distribution or copying of this email, and any attachments thereto, is strictly prohibited. If you have received this e-mail in error, please immediately and permanently delete the original and any copy of any email and any printout thereof.

[johnyanarella]

I think the latter -- it would be better to break that up into two chunks of work.

There's a fair amount of tweaking of configuration, etc. along the way to a successful execution of the Karma + Sauce Labs cross-browser testing + badge integration. Better to have the continuous deployment and cross browser / platform testing features as separate commits in case we need to revert or untangle which configuration changes apply to which feature.

I'm closing in on a successful integration of the Karma + Sauce + Badge feature into SWFService, so I'll be able to carry over some lessons learned (and even just clone some portions of the configuration). I'd be happy to tackle that part once the continuous deployment feature is up and running.