3 月，跳不動了？>>>
devops（development和operations的組合詞）是一種重視「軟體開發人員（dev）」和「it運維技術人員（ops）」之間溝通合作的文化、運動或慣例。透過自動化「軟體交付」和「架構變更」的流程，來使得構建、測試、發布軟體能夠更加地快捷、頻繁和可靠。[1]
可以把devops看作開發（軟體工程）、技術運營和質量保障（qa）三者的交集。
傳統的軟體組織將開發、it運營和質量保障設為各自分離的部門，在這種環境下如何採用新的開發方法（例如敏捷軟體開發），是乙個重要的課題。按照從前的工作方式，開發和部署，不需要it支援或者qa深入的跨部門的支援；而現在卻需要極其緊密的多部門協作。而devops考慮的還不止是軟體部署，它是一套針對這幾個部門間溝通與協作問題的流程和方法。[5]
需要頻繁交付的企業可能更需要對devops有乙個大致的了解。flickr發展了自己的devops能力，使之能夠支撐業務部門「每天部署10次」的要求[6]──如果乙個組織要生產面向多種使用者、具備多樣功能的應用程式，其部署週期必然會很短。這種能力也被稱為持續部署[7]，並且經常與精益創業方法聯絡起來。[8] 從2023年起，相關的工作組、專業組織和部落格快速湧現。[9]
[10]
[11]
[12]
devops的引入能對產品交付、測試、功能開發和維護（包括──曾經罕見但如今已屢見不鮮的──「熱補丁」）起到意義深遠的影響。在缺乏devops能力的組織中，開發與運營之間存在著資訊「鴻溝」──例如運營人員要求更好的可靠性和安全性，開發人員則希望基礎設施響應更快，而業務使用者的需求則是更快地將更多的特性發布給終端使用者使用。這種資訊鴻溝就是最常出問題的地方。
以下幾方面因素可能促使乙個組織引入devops：
使用敏捷或其他軟體開發過程與方法
業務負責人要求加快產品交付的速率
虛擬化[13]和雲計算基礎設施（可能來自內部或外部**商）日益普遍
資料中心自動化技術[14]和配置管理工具的普及
有一種觀點認為，當前佔主導地位的「傳統」美國式管理風格（「斯隆模型 vs 豐田模型」）[15]會導致「煙囪式自動化」，從而造成開發與運營之間的鴻溝，因此需要devops能力來克服由此引發的問題。
devops經常被描述為「開發團隊與運營團隊之間更具協作性、更高效的關係」。由於團隊間協作關係的改善，整個組織的效率因此得到提公升，伴隨頻繁變化而來的生產環境的風險也能得到降低。
在很多企業中，應用程式發布是一項涉及多個團隊、壓力很大、風險很高的活動。然而在具備devops能力的組織中，應用程式發布的風險很低，原因如下：
與傳統開發方法那種大規模的、不頻繁的發布（通常以「季度」或「年」為單位）相比，敏捷方法大大提公升了發布頻率（通常以「天」或「周」為單位）
減少變更範圍
與傳統的瀑布式開發模型相比，採用敏捷或迭代式開發意味著更頻繁的發布、每次發布包含的變化更少。由於部署經常進行，因此每次部署不會對生產系統造成巨大影響，應用程式會以平滑的速率逐漸生長。
加強發布協調
靠強有力的發布協調人來彌合開發與運營之間的技能鴻溝和溝通鴻溝；採用電子資料表、**會議、即時訊息、企業門戶（wiki、sharepoint）等協作工具來確保所有相關人員理解變更的內容並全力合作。
自動化強大的部署自動化手段確保部署任務的可重複性、減少部署出錯的可能性。
很多組織將開發和系統管理劃分成不同的部門。開發部門的驅動力通常是「頻繁交付新特性」，而運營部門則更關注it服務的可靠性和it成本投入的效率。兩者目標的不匹配，就在開發與運營部門之間造成了鴻溝，從而減慢了it交付業務價值的速度。
開發是由功能性需求（通常與業務需求直接相關）驅動的。
運營是由非功能性需求（例如可獲得性、可靠性、效能等）驅動的。
由於運營人員嘗試避免變更，新功能流入生產環境的速度因此被延緩，從而延緩了開發人員將特**付給使用者使用的速度。
運營人員可能對應用程式內部缺乏了解，從而難以正確地選擇執行時環境和發布流程。
開發人員可能對執行時環境缺乏了解，從而難以正確地對**進行調整。
一般而言，當企業希望將原本笨重的開發與運營之間的工作移交過程變得流暢無礙，他們通常會遇到以下三類問題：
發布管理問題
很多企業有發布管理問題。他們需要更好的發布計畫方法，而不止是乙份共享的電子資料表。他們需要清晰了解發布的風險、依賴、各階段的入口條件，並確保各個角色遵守既定流程行事。
發布/部署協調問題
有發布/部署協調問題的團隊需要關注發布/部署過程中的執行。他們需要更好地跟蹤發布狀態、更快地將問題上公升、嚴格執行流程控制和細粒度的報表。
發布/部署自動化問題
這些企業通常有一些自動化工具，但他們還需要以更靈活的方式來管理和驅動自動化工作──不必要將所有手工操作都在命令列中加以自動化。理想情況下，自動化工具應該能夠在非生產環境下由非運營人員使用。
要開始優化發布流程，可以從問題識別開始：看看上面提到的哪種問題在你的團隊中具有最高的優先順序。
這是企業級it組織中乙個新出現的角色，其主要任務就是協調安排將企業級軟體部署到預生產環境。對發布協調人的需求來自於以下幾方面原因：
需要彌合開發與運營的鴻溝
基礎設施日益變得複雜：為了運營web應用，需要多層基礎設施和多種平台
發布頻率上公升（由於敏捷和迭代式開發的引入）
分布式團隊：位於全球多個地點的、包含外包人員的、混合開發/測試/基礎設施的團隊
發布協調人的角色（也被稱為部署協調人或整合協調人）源自發布管理或發布工程團隊。這個角色與航空交通管制有些類似──實時協調不同團隊的行動，有效使用共享的資源（空域、航道、跑道、航站門），達到組織的總體目標（安全起降）。
傳統意義上的發布管理往往只關注軟體變更的計畫與管理，發布協調則需要控制「將特定軟體變更發布至生產環境」的整個過程。這項工作需要系統地管理所有與「將**構建並部署到生產環境」相關的技術任務，也被稱為「發布工程」。
變更管理是跟蹤企業it環境中各種變化──不管是應用程式還是基礎設施的變化──的基本原則。變更管理是itil v3的核心之一。
WIKI 維基百科
今天.我又了解了乙個新的東東.wiki.wiki一詞源自夏威夷語的 wee kee wee kee 本是 快點快點 之意。在這裡wiki指的是一種超文字系統，系支援那些面向社群的協作式寫作，同時也包括一組支援這種寫作的輔助工具。有人認為，wiki系統屬於一種人類知識的網路系統，我們可以在web的基礎...
維基百科 MediaWiki API 解析
使用開放的 api 做乙個自己的小專案，是乙個很好的學習方法。但好像開放的 api 選擇並不多。這裡給大家多乙個選擇，簡單介紹一下維基百科使用的 mediawiki api。先簡單介紹幾個容易混淆的概念。wiki 是一種在網路上開放且可供多人協同創作的超文字系統。wiki 站點可以由多人維護，不同人...
收藏 REST 維基百科
表徵狀態轉移 英文 representational state transfer，簡稱rest 是roy fielding博士在2000年他的博士 中提出來的一種軟體架構風格。目前在三種主流的web服務實現方案中，因為rest模式的web服務與複雜的soap和xml rpc對比來講明顯的更加簡潔，...