開發維運

關於開發維運可以找到上千的不同定義.大部分都是談到文化流程和工具.以上都沒錯.都是開發維運重大變革的一部分.

開發維運的木的是讓軟體開發團隊重申他們的工作所有權.如同我們熟知當我們把人在一連串的工作中拆開不好的事就會發生.

整個開發和維運團隊必須為這應用的成果負責任.

對開發者而言沒有比把在量產前時把倉庫的程式碼擺上一個月不動要來得更沮喪.我們需要再交付某些事物跟看見讓他們生活中不一樣中重新找回他們的亮點

我們需要更快交付軟體還有更安全.但我們仰賴什麼樣的藉口使我們避免交付它?

在訪問上千不同由小到大,財務機構到電子商務公司的開發團隊,我可以認定第一名藉口就是臭蟲.

我們沒更快交付軟體因為每一次的量產發行創造了一大堆的臭蟲.

下一個疑問是：在量產時什麼引起臭蟲？

這一個也許容易回答：在每一次量產發行時引起臭蟲的原因就是在程式碼與環境的變.他們嘗試一部分掉落當我們改變時

但我們不能用這個藉口去不變！改變是我們生活的一部分,最終是我們唯一真理.

讓我們嘗試在變與臭蟲間做一個簡單的修正.在每一次我們的發行中多變,多臭蟲.這不是合理嗎？更多混雜在我們的程式基礎上,更像是在某處上更混雜.

傳統試著用來解決問題的方式是有更多的時間測試.如果我們每週交付程式我們需要兩週因為我們需要測試更多.如果我們每月交付程式我們現在需要兩個月等等.這不難想像遲早有些團隊在週年慶才發布軟體

這樣的走向聽來違反經濟.交付軟體經濟導向去產生更少的臭蟲是相對的.我們需要交付更頻繁而且我們也要降低在不同版本間的改變.在版本間更少的變,會有更少在新量產版本引起的臭蟲

甚至我們在量產仍有臭蟲如果我們只變更少部分幾行的程式這些臭蟲的來源又能在哪呢.更小的變更容易聚焦臭蟲來源.也更容易修正他們

在開發維運專業術語中摘要這些變化在不同軟體版本間叫做批次尺寸.所以如果我們要去計算我們在開發維運中的準則他將會是

減少你的批次尺寸至你能處理可允許的最小化

為達成這你需要一個完全自動軟體開發產線這樣的流程與工具在一個大藍圖一起但你所做的一切依序是減少你的批次大小

不同環境引起的臭蟲是最糟的

當我們處理臭蟲時,我們通常有日誌紀錄,堆疊追蹤,除錯器等等但就算有以上全部,我們依舊大叫 但這在我的機器上可運作

這可怕的情境-程式在你的機器可運行但量產上不行-這是由於你的環境的不同所造成.你有不同的作業系統 不同的核心版本

不同的關聯版本 不同的資料庫驅動程式等等.事實上這樣驚訝的事更多發生在量產上.

你必須開發.測試和執行你的應用程式在開發環境-這越接近量產環境越好,在你自己的開發環境或許沒法有甲骨文RAC和多工的Xeon 伺服器但你可以有相同Oracle和核心版本或相同的應用伺服器在虛擬機

架構如同程式的工具如同Ansible,Puppet 和Chef真正的響亮,在多工的環境自動基礎設定.我們強烈呼籲使用他們並匯入這些代碼在你的應用中.這通常符合環境設定與應用程式中為什麼他們不能版控在一起呢？

容器技術提供很多優點但特別適用透過包裝應用與環境在一個容器單元解決不同環境設定.更特別的包裝應用與環境在一個單一單于的結果叫做虛擬應用.你可以透過虛擬機設定虛擬應用但通常大且慢於啟動.容器透過最小化虛擬應用大小與啟動時間把虛擬應用在同一個層級.並提供一個簡易的方式去分散和消化容器映像

另一個廣泛的工具是Vagrant,Vagrant 做得更甚多,它創造了一個升等工具你可以輕易的設定開發環境相近於如你的量產環境.

你的文字只需要一個Vagrantfile, 一些設定和一個簡單的vagrant up 指令, 你就可有一個與開發相關待執行的完整功能的虛擬機或容器