※ 引述《Sanbeishuu (三杯鼠)》之銘言：
: 請問主流的幾款自動化佈署軟體有無較適合單純的update某個web application的呢?
: 一開始試了Jenkins，發現他好像不是這樣的用途。後來才發現應該是其他的像是
: Puppet, Chef, SaltStack, Ansible, Juju?
: 目前看起來1跟2是Ruby派，3跟4是Python派，小弟是純Java派，所以沒特別偏好。
: 但如果可以的話是傾向Py派，但其實各款的script好像也不一定是用Py或Ruby寫..
: 主要使用情境如下:
: 1. Standalone & portable
: 希望是可以單純locally的去run，run這一台機器本身的deployment。
: 貌似這類軟體都是為了cloud management，所以都有server/client的架構。
: 目前只先略略survey了Chef，應該是有單純Chef-client跑CookBook的功能。
: SaltStack有看到masterless跟standalone的documentation的樣子。
: 另外還希望這是可以portable的，也就是我可以調整好script後打包起來，
: 然後交給客戶在on-premises的情境下，double click去完成deployment。
: 2. 只單純的deploy一個Java web application到tomcat
: 沒有要做複雜的server setup跟provisioning。想達到的其實只是單純的
: upgrade某個web application而已。所以整個flow有點類似以下這樣
: 已經有一個application跑在tomcat。該application有a.xml跟b.properties檔案
: a.xml的內容會類似如下
: <Property>
: <Name>ServerURL</Name>
: <Value>192.168.1.2</Value>
: </Property>
: b.properties的內容會類似如下
: database.host=192.168.112.25
: database.port=5432
: 有一個新的版本出來了，當然他是一個war檔。war檔內一樣有a.xml跟b.properties
: 只是這時war檔內的這些configure値會是default狀態。例如:
: <Property>
: <Name>ServerURL</Name>
: <Value>localhost</Value>
: </Property>
: database.host=127.0.0.1
: database.port=5432
: 自動化的把war檔解壓，將a.xml跟b.properties內容與正在運行的
: application有不同的地方做更改。然後可能必須在壓回去war包，
: call tomcat的rest API去進行deploy，如此將web app upgrade，
: 又不需要人工去處理這些application properties的設定値。
: 3. Windows platform
: Tomcat跑在Windows平台上(Win7, Win10, Win Server 2008, 2012 etc..)
: 所以等於是master跟client或者說standalone的運行是在Windows平台上。
: Chef有Windows的msi安裝檔，還沒確定是否可以portable的包起來。
: SaltStack的getting started doc都是Linux版本的範例..
: 4. Free~
: 目前看到Chef, Ansible, SaltStack都有付費版本或者提供SaaS。
: 但應該都有真正的freeware版吧? Ansible看不太出來
: 只有一個Ansible Tower Free trial
: 不知道有沒有大大可以建議一下哪一款比較適合簡單的達到這個的佈署呢?
: 感謝
去年的10月開始，我開始撰寫公司新的Java Web Application Deploy方式，
我的目標也跟你很接近，我想要做一個每個人只要click一下就能完成所有建
置與部署的功能，然後在部署的同時也可以根據不同的環境設定放入不同的
properties file，我一開始的時候也是survey chef後來學了Ansible之後開始
想用Ansible，但最終我捨棄這些工具，最後是全部自己搞定。
想說其實很難，但其實也不太難，因為部署這件事情，其實是很容易標準化的
動作。
我們的平台有一個非常大的前提是，我們的網站規模非常非常大，是一個ERP應用
的層級，而且不是採取microservice架構，所有裡面內含的其他應用都不算，光是
把登入頁面加上所有dependency(Spring 4 + JesperReport + ....)這些東西包起
來，就要80M，其他東西加上去以後包出來的war太大，所以一開始我就捨棄了用war
來封裝這種做法，整個build+deploy+生效的時間會太長了，長到我沒有辦法接受。
所以每個同仁開發的都是一個網站的其中一個library(包含Java Source跟Javascript
等靜態檔案）
Jenkins除了build之外也可以拿來package跟deploy，但deploy並不適合我們這種場
景，所以Jenkins其實在我的系統裡面是拿來build完之後把lib送到repository裡面
。
deploy完全是自己寫的，因為除了以上的原因之外，我還有需要用Tomcat的parallel
deployment，這東西其實很簡單，但是沒有很好的tool做這種事情。
集合以上兩點我開始自幹一套部署平台來整合Jenkins跟Nexus, Sonarqube還有Doxygen
，因為是標準化程度很高的應用程式，所以比起用上Ansible這類的工具，其實自幹
還比較快，也不用讓別人多學別的工具，你所需要的工具，頂多就是Jtsch跟JGit之類的
工具而已，純Java的東西。
http://imgur.com/a/8wSMK
像這樣，所有的版次都是這個平台自己產生提供給Gradle
http://imgur.com/a/nrK3o
每個系統目前部署的情況也可以一目瞭然
如果要部署到測試環境，只要按一下按鈕就可以部署，如果你的系統會被多個網站共用
，由於自己管理叢集資訊，所以也可以一次部署到多個地方
如果是正式環境就再加上一些比較複雜的簽核流程給給主管簽核後上線。
因為全部都是你自己寫的，所以你不用去思考怎麼用這些DevOps工具去整合或幹麻，
又因為是集中式的架構，客戶的部署也是由你自己的平台來進行，如果這種直接開ssh
tunnel部署類似Ansible的方式不方便，其實也可以多做一個Agent代你完成部署工作，
，所以最終我決定全部都自己來做。其實花得時間並不會真的那麼長。
整個建置程序都有Jenkins跟Gradle代勞，deploy要做的頂多就是把檔案傳到正確的
位置，然後透過諸如調整load balancer或是parellel deployment的方式縮短或避免
downtime，然後用healthy check來確保東西正常運作然後要不要繼續部署下去而已，
沒有很複雜。
當然現在更好的方式就是把整個application封裝成container來deploy，那要看你們對於
container相關技術的接受程度有多高了