本文延續 上篇文章說明一個山姆鍋利用 Jenkins 建構的持續整合系統，這個系統跟 Google Apps for Business 認證整合 (或者也可以使用其它 OpenID providers)。按照建議的架構，採用 Master-slave 叢集方式，團隊可以視需要增減 slave 服務器。

過去文章中，山姆鍋提到「影化身科技」的官網以及部落格使用靜態網站產生軟體，Octopress，來建構與管理。本文的目的是整理過去以及未來相同主題的文章，讓讀者可以有連貫的概念關於為什麼要使用靜態網站，如何架設以及網站維護種種實際遇到的問題。

為了希望能夠儘早的得到潛在用戶的反饋，「影化身科技」一開始就打算設置客戶服務系統。這樣的系統，由於主要面向用戶，因此，不能全然以技術面向來考量。跟持續整合一樣，客戶服務系統提供敏捷開發流程重要的反饋，從而讓讓團隊可以不斷學習用戶真正需求以設計真正需要的產品。 本文屬於 「善用雲端服務，微型企業的自強之道」系列文章之一。

「影化身平台」的設計目標之一是高可用性 (high availability)，而為了達到這個目的，基本上就表示系統的所有元件都要有冗余 (redundancy) 容錯 (fault-tolerancy) 的特性，以避免成為單一失敗點 (SPOF)。「高可用性」是個很大的課題，本文山姆鍋只先針對資料本身的可用性來說明「影化身平台」採取的解決方案以及使用的理由。

使用 Maven 或 Gradle 等軟體建構工具 (build tool) 常常會需要使用 Maven 套件倉儲 (artifacts repository) 來作為套件存放的地方。過去山姆鍋習慣使用 Nexus Repository Manager 來作為這樣的套件倉儲服務器， Artifactory 雖然沒用過，看起來也很不錯。本來不加思索打算按照習慣用 Nexus 安裝個套件倉儲，或者使用 Artifactory 看看也很新鮮，但突發奇想：可不可以使用 Amazon S3 來作為 Maven repository？有什麼問題跟限制？

對於在 Java 平台上，部署過後台服務器的人來說，讓 Java 程式以 Windows/Linux 服務 (daemon) 形式執行，是一個常見的問題，這裡的以 “服務方式” 是指該程式會隨系統啓動而自動執行，甚至更好的話，該程式如果異常結束會被重新執行。過去，山姆鍋跟多數的人一樣，選擇 Java Service Wrapper，不過自從它在 3.2.3 版本以後改了授權，雖然仍可以繼續使用 3.2.3 版本，但相信很多人也跟我一樣想尋找其他替代方案。

電子郵件可以說是一家公司最基本的聯絡工具，而擁有自己域名的電子郵件位址，不管公司大小，對於專業形象來說都是很重要的一件事。「影化身科技」使用 Google Apps，自然使用其作為電子郵件服務。但是，除了 Google Apps，還是有其他不錯的選擇。本文是 「善用雲端服務，微型企業的自強之道」系列文章之一。

在部落格發佈新文章自然會希望讓別人能更快發現或搜尋到。之前使用的 WordPress 有相關的插件可以簡單做到這件事。幸好，Octopress 上面的方案也並不難，本文山姆鍋就來分享我是如何讓「影化身部落格」在發佈新文章時可以通知搜尋引擎。

山姆鍋曾經提到，影化身網站是放置在 Amazon S3 上，也利用 CloudFront 來減少存取的延遲。 但是，好還可以更好，山姆鍋在本文會分享如何減少 HTTP 要求數量，壓縮網頁內容來加快存取速度。