企業的組織形態和經濟形態決定了 devops 的方案。
到今天為止，實習了四個多月了。粗略了解了下 devops的概念，簡單記錄下。
當我們還在學校寫專案的時候，由於專案規模較小，基本都自己乙個人寫完**，自己測試，測試功能沒有問題之後，自己部署專案到伺服器，結束！
後來，到公司工作了，專案越來越大，乙個**需要幾千甚至上萬人在開發，乙個人的力量畢竟是有限的，就會有乙個大團隊在一起開發專案。這麼多人工作於乙個專案，沒有明確的分工肯定是不行的，為了達到高效率的工作，工作職能出現了細化，需求-----開發----測試-----運維，每個階段都有專屬的人去做，大家各不相干。於是傳統的瀑布模型也就是這樣的，最上面的boss 安排好開發方案，交給開發人員，經過若干時間，開發完了交由測試人員去做測試，又經過若干時間，不幸的話，會測出一堆bug，然後再給開發人員去修復，修復完了再測，反反覆覆，直至最後測試通過，交由運維人員部署專案，上線，給廣大使用者使用。
這樣最大的缺點就是每個階段所需要的週期太長了，得到反饋的時間也太久了，造成整體開發效率低下，很不友好。後來出現了敏捷開發模式，大意就是把需求--開發--測試綁在一起，大家一塊工作，需求發出一部分，就先開發一部分，開發好了，直接交由測試，這樣乙個乙個小功能，小的模組測試，得到反饋的速度提高了很多倍，整個專案的優化是迭代式的，一步一步在改善，開發的效率無形中提高了很多，大家都很開心。
時間久了，敏捷開發雖然把 需求--開發--測試 糅合到了一起，但是和運維人員之間還有一堵牆存在，開發人員和運維人員的目標是不一樣的，開發想的是多改變**，多修正問題；而運維人員追求的是穩定性，盡可能的小改動。每次改動乙個版本再去上線需要很多配置步驟，變動太大，每次部署也很麻煩，運維人員不開心，專案部署失敗，大家都不好過。
這時候，就出現了一種新的模式，也就是devops, 開發人員和運維人員的簡寫。可以看做在敏捷開發的基礎之上，再把運維人員也糅合進來，每次乙個小功能的測試完成，就立即上線，最大的好處就是可以極速的得到使用者的反饋，然後把修改意見傳給開發人員，進行再次修改，測試，上線。這樣一來，乙個專案可能在一天之內上線好多次，每次改動也不會太大，運維人員也舒服了，最大的好處在於得到使用者的反饋速度提高了n倍！！ 這些反饋無疑是非常重要的，有了使用者的體驗反饋，我們可以更快的做出相應的改變，以滿足使用者體驗感，在這個網際網路時代，高效，快速是非常非常重要的。
學習DevOps的熱門原則
原文 popular tenets to learn devops譯者注 devops development和operations 是一組過程 方法與系統的統稱，用於促進開發 應用程式 軟體工程 技術運營和質量保障 qa 部門之間的溝通 協作與整合。它的出現是由於軟體行業日益清晰地認識到 為了按時...
設計原則與思想 設計原則
如何理解單一職責原則 srp solid原則並非單純的1個原則,而是由5個設計原則組成,他們分別是 單一職責原則,開閉原則,裡式替換原則,介面隔離原則和依賴反轉原則,依次對應solid中的s,o,l,i,d這五個英文本母 單一職責原則的英文是single responsibility princip...
設計原則 開閉原則
開閉原則的含義是對擴充套件開放，對修改關閉。意思就是在遇到新的需求或者變動的時候，提倡對原 擴充套件使其滿足新的需求，不提倡修改原 來達到目的。乙個專案不可能在開發完畢後就一成不變了，它總會有新的需求或者對老的需求進行更新。這樣就要盡可能的遵從設計原則中的開閉原則，這個原則告訴我們，要盡量避免對原 ...