Automated deployment

[jykae]

Configure automated deployment using Travis CI.

Blog article: https://sungwoncho.io/meteorjs-continuous-delivery/
Github example: https://github.com/sungwoncho/meteor-continuous-delivery

[brylie]

See also the 'Adding CI' support section of this article: https://atmospherejs.com/i/publishing

There is a quick example of a Meteor CI script:

language: node_js
node_js:
- "0.10"
before_install:
- "curl -L http://git.io/ejPSng | /bin/sh"

The shell script linked to in the curl command looks like this:

#!/bin/sh

#configuring the system
wget https://raw.github.com/arunoda/travis-ci-meteor-packages/master/Makefile
wget https://raw.github.com/arunoda/travis-ci-meteor-packages/master/start_test.js
wget https://raw.github.com/arunoda/travis-ci-meteor-packages/master/phantom_runner.js

#install meteor
curl https://install.meteor.com | /bin/sh

#installing meteorite
npm install -g meteorite

[jykae]

Encryption key & iv are stored as environment variables and seem to have problems with Travis: pockethub/PocketHub#884

I am getting the same error "iv undefined".

[jykae]

Environment variables were not successfully loaded cause I didn't have admin rights yesterday when I made file encryption. Made that again and got it working.

[jykae]

Yay, successfully deployed to APIKA staging using Travis. I had to remove android platform. I will put ticket about this. I suppose building Android .apk is not necessary?

[jykae]

@brylie I think making Meteor package is not the case here. Travis CI runs the Meteor Up deploy command (builds & uploads the application to server).

Next steps: define when to launch build. With Travis API it's also possible to launch builds periodically rather than on push & pull request. Periodically might be ok for APIKA. Apinf master-branch mirror update happens once a week, so could be fine to run Travis also weekly.

[brylie]

The article simply describes adding CI support for Meteor.js code. It applies equally well to Meteor projects. It was for reference purposes.

[jykae]

This needs some kind of a plan for the schedule, and discuss how we sync with Apinf. Or should I put Travis deployment for "staging" against "develop" branch? Currently it uses "master" branch.

Master branch will be mirrored anyway, but if there is not specific schedule for releases and we're not deploying straight to production, that could be done manually when we decide to move to new release.

What you think @brylie @bajiat?

[brylie]

Staging can use the develop branch, just with the understanding that develop contains alpha releases. I.e. we are still adding features to the develop branch :-)

[bajiat]

Alternatively, we could decide to make a couple of stable releases (from
master) in Apika timeframe. That would require e.g.testing workshops on the
releases.

2015-11-23 15:43 GMT+02:00 Brylie Christopher Oxley <
notifications@github.com>:

Staging can use the develop branch, just with the understanding that
develop contains alpha releases. I.e. we are still adding features to
the develop branch :-)

—
Reply to this email directly or view it on GitHub
https://github.com/apinf/api-umbrella-dashboard/issues/631#issuecomment-158936087
.

---

Taija Björklund
p. 040 5177 969
taija.bjorklund@gmail.com
www.linkedin.com/in/taijabjorklund

[jykae]

Update: I'll continue next week with different approach. We talked shortly in the daily about using nightly.apinf.io for "develop" branch deployments, so that it would benefit the project. I need access to that server to deploy there.

[brylie]

@ccsr or @elnzv, will you please give @jykae access to the nightly.apinf.io server?

@jykae, check out the travis.yml file in Telescope, as it is very similar to what we are aiming for in terms of testing and deployment.

[ccsr]

@brylie, @jykae has access to it already
@jykae you should have access to it as I created for your regarding Zabbix project

[jykae]

@brylie @elnzv Good! Here's also nice guide, that gives better understanding (imho) than few mysterious lines, https://docs.travis-ci.com/user/gui-and-headless-browsers/
Meteor Up supports PhantomJS, so this should be a good way to go.

[jykae]

And in the high abstraction level, is this Telescope frontpage (demo & Heroku deployment) something we would like to have for the product? Magical deployment by pressing the button :) More on Monday planning..

[jykae]

@brylie Cucumber would complement Jasmine nicely, http://xolv.io/blog-posts/2015/11/6/the-seven-testing-modes-of-meteor

Example: https://coderwall.com/p/qj9d0w/testing-meteor-with-cucumberjs

PhantomJS could be used instead of Zombie, I suppose. Zombie is webkit emulator, PhantomJS has full webkit support.

Aftermath feat. imho

Automated acceptance testing like in the example above, could be something we could have for adding features like Sign up, Login, Add backend etc. It might help to tackle the basic problems before the bugs go to the release. That could be something for person in the team who is working with integration & deployment.

[kyyberi]

I've used cucumber in the past and it was great.

[brylie]

@jykae and @kyyberi it looks good. We are a bit off-topic here, so I will create a new issue.

[jykae]

@brylie Yep, testing stuff to another issue :)
I have access to "nightly" server and will proceed with Travis CI deployment and use "develop" branch for it.
@brylie I will request "admin" rights to Apinf organization, Travis requires it.