Auto-deploy via Travis-CI

[tknerr]

Whenever we do changes in the source branch, we need to build the website via gulp and commit / push that to the master branch.

This shouldn't be a manual task. Instead, it should happen automatically whenever we push something to the source branch. We could use travis-ci to do that automatically for us.

For setting up travis-ci to auto-deploy / push to master this blog post will help: http://benlimmer.com/2013/12/26/automatically-publish-javadoc-to-gh-pages-with-travis-ci/

Afaik we don't have a zuehlke travis-ci account yet, so we should do that first and add it to the Cloud Repositories page in the IKM.

Note that this plays nicely together with feature branches and pull requests (aka the GitHub Flow). Consider the following workflow:

1. create a feature branch feature/xyz from source to develop xyz
2. whenever you made progress, push that to feature/xyz on origin (=this repo). Travis-ci will happily build and test every feature branch for us.
3. create a pull request (from feature/xyz -> source) as soon as want someone to review or comment on your changes
4. If review done, merge the pull request
5. Travis-ci will detect the new commit on source and build that too. As it sees this is a build from the source branch (via the $TRAVIS_BRANCH env var), it will auto-deploy the changes to http://zuehlke.github.io by commiting / pushing the build result to master

[michaelschnyder]

Is travis a requirement or would teamcity also work? Tobias and I would ne able share our hosted teamcity... Not yet anounced in public, btw.

---- Torben Knerr wrote ----

Whenever we do changes in the source branch, we need to build the website via gulp and commit / push that to the master branch.

This shouldn't be a manual task. Instead, it should happen automatically whenever we push something to the source branch. We could use travis-ci to do that automatically for us.

For setting up travis-ci to auto-deploy / push to master this blog post will help: http://benlimmer.com/2013/12/26/automatically-publish-javadoc-to-gh-pages-with-travis-ci/

Afaik we don't have a zuehlke travis-ci account yet, so we should do that first and add it to the Cloud Repositories page in the IKM.

Note that this plays nicely together with feature branches and pull requests (aka the GitHub Flow). Consider the following workflow:

1. create a feature branch feature/xyz from source to develop xyz
2. whenever you made progress, push that to feature/xyz on origin (=this repo). Travis-ci will happily build and test every feature branch for us.
3. create a pull request (from feature/xyz -> source) as soon as want someone to review or comment on your changes
4. If review done, merge the pull request
5. Travis-ci will detect the new commit on source and build that too. As it sees this is a build from the source branch (via the $TRAVIS_BRANCH env var), it will auto-deploy the changes to http://zuehlke.github.io by commiting / pushing the build result to master

---

Reply to this email directly or view it on GitHub: https://github.com/Zuehlke/zuehlke.github.io/issues/1

[tknerr]

Wouldn't say there is a requirement to use travis, it's just that the combination of travis + github is so common. Probably because travis is available as a hosted service for free (for open source projects).

And while I'm writing this... @carstenkind @bruderol: DOH! :grimacing:

Travis CI is free for Open Source projects -> means we can only use it for public repositories, unless we want to pay 129$ / month... :-/

Using CircleCI would be an alternative, as they also support private repos in their free plan (actually one of the reasons I favor circleci, but it's still less common than travis...).

However, I like the idea of @michaelschnyder and supporting a hosted TeamCity solution developed by zuehlke! :+1: :+1: :+1: :)

[carstenkind]

@michaelschnyder :+1: Of course it can be your solutions. Obviously we can't use Travis CI. Feel free.