Setup Travis to deploy site to S3 after each successful build

[iluwatar]

The web site is now manually published at http://java-design-patterns.com for which the backend resides at Amazon S3.

We need automatic deploy process so we can immediately see the changes on the site.

[zafarella]

Those presentation also can be added to the page?

[iluwatar]

@zafarella I think we're not ready to integrate with the web site yet. We can keep them in /etc folder or some other name.

[iluwatar]

@noobxgockel @npathai I'm thinking about moving the web site sources to the master branch. I understand this requires some changes to how things work at the moment. For example the submodule system would not be needed anymore since the design patterns source code would be in the same branch.

We could put the web site source code into web folder of the master branch. Then we could add Jekyll spells to the Travis configuration to build the static web site on each commit e.g. jekyll build --source <source> --destination <destination>. The build web site would then be available at web/_site and we could deploy it to S3 with something like this:

deploy:
  provider: s3
  access_key_id: AKIAJVPJZO7743HVSDHA
  secret_access_key:
    secure: iHjLIy+dHku1o8PrjGhz1mMfM971nqmpjo2mzVNYqYrxlB8zoAqwlz9LoFJcUAKbxhHLJT/LgtYYj+uBspUMOITejaiyCDcM8edGwSXKJu+g+Fp0PVGZQXGziGInmUVT9b2lpAV8Nn2sRpAHgHrM9fKaAU3epG5LfVkQxSkGZp0=
  bucket: java-design-patterns.com
  local-dir: web/_site
  acl: public_read
  skip_cleanup: true
  on:
    branch: master

Let me know what you think about this kind of change.

[markusmo3]

@iluwatar
Yes we could do that, the only issues i am seeing is that your approach isnt 'free as in speech' because of the server costs of s3 and its not self-sustainable if s3 fails/gets cancelled because we'd have to change the source code yet again to convert another host like gh-pages or other hosting services.

If possible by any means i'd suggest staying with the inhouse solution for website hosting of github, the github-pages. It's free and doesnt introduce 3rd parties to the project.

Moving the website to the master branch will completely break github-pages compatibility. Jekyll is a big ruby gem with lots of dependencies and we have quite a big website, im not sure if travis has any restrictions for OS projects on this. Lastly the Bus Factor for website hosting would be 1 because you are the only one with access to your s3 account and thats most of the times a sign for bad organization.

Of course it would have some advantages too, we could use jekyll plugins or write our own ones for very exotic website features. We could introduce more 3rd parties like cloudflare or mobile optimization.

TL;DR
All in all it definitly is a hard topic to decide upon. But in the end, i'd vote for staying with the gh-pages hosting. ATM the only advantage for using s3 i am seeing is the domain, are there any other ones ?

[npathai]

@iluwatar I didn't get the reason why we need to move web site to master for automatic S3 deployment. I understand the concerns of @noobxgockel . But again as I am not familiar with jekyll I can't say much on this. But one thing is for sure it would be good to have automatic deployment.

[iluwatar]

Thank you guys for your valuable input. As @noobxgockel well justified we should not break the working Github Pages system. So until I find an automatic way that doesn't break anything I'm going to manually deploy to http://java-design-patterns.com

@npathai it was the only way I could invent for automatic Jekyll build & deploy to S3. But I'll try to find another way.