6.DevOps 和敏捷開(kāi)發(fā)
康威定律?說(shuō)：設(shè)計(jì)系統(tǒng)的組織，最終產(chǎn)生的設(shè)計(jì)等同于組織之內(nèi)、之間的溝通結(jié)構(gòu)。
因此，一個(gè)公司的前端、后端和數(shù)據(jù)庫(kù)團(tuán)隊(duì)可能會(huì)傾向于使用三層架構(gòu)。在很大程度上，應(yīng)用程序的結(jié)構(gòu)，是由組織溝通后產(chǎn)生。簡(jiǎn)而言之，形式是交流的產(chǎn)物。
在本文中，作者學(xué)習(xí)康威定律并應(yīng)用到自己的組織。
以下為摘錄:
傳統(tǒng)的瀑布式開(kāi)發(fā)模式已經(jīng)為我們的應(yīng)用程序定義一個(gè)特定的溝通結(jié)構(gòu)：
開(kāi)發(fā)開(kāi)發(fā)人員讓（QA）團(tuán)隊(duì)測(cè)試并質(zhì)量保證，QA 讓運(yùn)維（OPS）團(tuán)隊(duì)去部署。
這種方式的溝通，是非敏捷的，加重了我們有缺陷的組織結(jié)構(gòu)，這又是一個(gè)印證了康威定律的例子：組織結(jié)構(gòu)決定產(chǎn)品。
閱讀完整的文章， DevOps 和敏捷開(kāi)發(fā)，請(qǐng)?jiān)L問(wèn)
https://blog.sei.cmu.edu/post.cfm/devops-agile-317
7. DevOps 團(tuán)隊(duì)需要 ChatOps
項(xiàng)目團(tuán)隊(duì)關(guān)鍵利益相關(guān)者之間的對(duì)話（例如，開(kāi)發(fā)人員、業(yè)務(wù)分析員、項(xiàng)目經(jīng)理、安全團(tuán)隊(duì)），平臺(tái)之間的溝通，可以對(duì)協(xié)作產(chǎn)生深遠(yuǎn)的影響。
較差的或甚至沒(méi)有使用通訊工具，導(dǎo)致溝通不暢，重復(fù)的工作，或錯(cuò)誤的實(shí)現(xiàn)。另一方面，開(kāi)發(fā)和業(yè)務(wù)基礎(chǔ)設(shè)施相結(jié)合的通信工具，可以加快向組織交付業(yè)務(wù)價(jià)值。
也就是說(shuō)，一個(gè)團(tuán)隊(duì)如何組織基礎(chǔ)設(shè)施結(jié)構(gòu)，如何溝通，將直接影響團(tuán)隊(duì)的效率。
在文章 DevOps 團(tuán)隊(duì)需要 ChatOps 中，作者介紹了 ChatOps，DevOps 的一個(gè)分支，關(guān)注 DevOps 團(tuán)隊(duì)的溝通。
ChatOps 包括了團(tuán)隊(duì)的溝通和協(xié)作工具：通知、聊天服務(wù)器、機(jī)器人、問(wèn)題跟蹤系統(tǒng)等等。
以下為摘錄:
在最近的一篇博客?中，作者寫(xiě)道，ChatOps，一詞起源于GitHub上，都是關(guān)于基于對(duì)話的驅(qū)動(dòng)開(kāi)發(fā)方式：
“把你的工具帶到您的溝通過(guò)程中，并使用一個(gè)聊天機(jī)器人修改關(guān)鍵的插件和腳本工作，團(tuán)隊(duì)可以自動(dòng)執(zhí)行任務(wù)和協(xié)作工作，使工作更好、更便捷、更快”。Sigler寫(xiě)道。
大多數(shù)團(tuán)隊(duì)在聊天服務(wù)器上都有一定程度的合作。聊天服務(wù)器可以作為一個(gè)城市廣場(chǎng)一樣容納開(kāi)發(fā)團(tuán)隊(duì)、促進(jìn)團(tuán)隊(duì)之間的凝聚力、討論實(shí)際問(wèn)題以及潛在解決方案等。
我們希望所有的團(tuán)隊(duì)成員使用聊天服務(wù)器。在我們的團(tuán)隊(duì)中，為了避免一般聊天室的灌水聊天，我們也創(chuàng)建專用聊天室，每個(gè)項(xiàng)目，項(xiàng)目團(tuán)隊(duì)成員可以談?wù)擁?xiàng)目的細(xì)節(jié)，不涉及其他的團(tuán)隊(duì)：
和其他簡(jiǎn)單的溝通介質(zhì)不一樣，聊天服務(wù)器可以智能化，開(kāi)發(fā)的基礎(chǔ)設(shè)施，向團(tuán)隊(duì)傳遞通知，團(tuán)隊(duì)執(zhí)行命令并反饋回基礎(chǔ)設(shè)施。
我們的聊天服務(wù)器是通知的樞紐，與我們的基礎(chǔ)設(shè)施快速互動(dòng)：
項(xiàng)目團(tuán)隊(duì)通過(guò)聊天服務(wù)器接到通知（還有其他方法），關(guān)注基礎(chǔ)設(shè)施任何生成狀態(tài)，他們關(guān)注：構(gòu)建失敗、構(gòu)建成功、超時(shí)等。
閱讀完整的文章，DevOps團(tuán)隊(duì)需要ChatOps，請(qǐng)?jiān)L問(wèn)
http://blog.sei.cmu.edu/post.cfm/chatops-in-devops-team-029
8.DevOps之Vagrant
環(huán)境等同?是一個(gè)理想的、令人充滿期待的狀態(tài)。缺乏環(huán)境等同會(huì)使軟件開(kāi)發(fā)陷入令人沮喪的困境。部署和開(kāi)發(fā)都經(jīng)常會(huì)陷入這樣的陷阱，降低了穩(wěn)定性、可預(yù)測(cè)性和生產(chǎn)力。
當(dāng)環(huán)境不等同時(shí)，這使得故障難以排除，而且難以協(xié)作。這種缺乏環(huán)境等同使開(kāi)發(fā)人員和運(yùn)維人員負(fù)擔(dān)太多。
在這篇博客中 DevOps 之 Vagrant ，作者描述了 Vagrant：
這是一個(gè)開(kāi)發(fā)者使用的工具，提供了一個(gè)虛擬化和環(huán)境配置，Vagrant 為開(kāi)發(fā)者提供了一個(gè)單一的，聲明式腳本，以及一個(gè)簡(jiǎn)單的命令行界面。
通過(guò)使用相同的預(yù)先配置的 Vagrant 腳本，Vagrant 為所有開(kāi)發(fā)者統(tǒng)一了線上的環(huán)境。在應(yīng)用開(kāi)發(fā)生命周期過(guò)程中，Vagrant 消除了“環(huán)境不同”的借口。
以下為摘錄:
運(yùn)維團(tuán)隊(duì)的作業(yè)通常包括在所有部署環(huán)境中實(shí)施全面的校驗(yàn)，例如用于測(cè)試、分段和上線。
相反，開(kāi)發(fā)團(tuán)隊(duì)幾乎完全自己負(fù)責(zé)配置開(kāi)發(fā)機(jī)器。為了達(dá)到百分之100的環(huán)境等同，兩個(gè)團(tuán)隊(duì)必須使用相同的語(yǔ)言，使用相同的資源。
Chef和Puppet，這兩個(gè)都是為運(yùn)維而生，對(duì)一個(gè)繁忙的開(kāi)發(fā)人員來(lái)說(shuō)可能不太友好。
Chef和Puppet都有一個(gè)比較陡的學(xué)習(xí)曲線，并沒(méi)有真正解決環(huán)境等同的問(wèn)題：
開(kāi)發(fā)者仍然需要和線上環(huán)境同步。
所有這些額外的工作會(huì)帶來(lái)一個(gè)相當(dāng)大的開(kāi)銷(xiāo)，而開(kāi)發(fā)者只想好好的寫(xiě)業(yè)務(wù)代碼！
這就是Vagrant出現(xiàn)的意義。Vagrant是一個(gè)面向開(kāi)發(fā)者的工具，基本上Vagrant提供了一個(gè)虛擬化環(huán)境，提供了一個(gè)單一的，聲明式的腳本和一個(gè)簡(jiǎn)單的命令行界面。
Vagrant通過(guò)啟動(dòng)一個(gè)虛擬機(jī)（VM），去除繁重的工作，消除了人工配置或運(yùn)行，例如，chef-server和chef-client。Vagrant的隱藏這一切，提供一個(gè)簡(jiǎn)單的腳本給開(kāi)發(fā)人員，一個(gè)名叫Vagrantfile無(wú)擴(kuò)展項(xiàng)文件，可隨著代碼簽入到源代碼控制。
閱讀完整的文章，DevOps之Vagrant，請(qǐng)?jiān)L問(wèn)
https://blog.sei.cmu.edu/post.cfm/devops-technologies-vagrant-345
9.使用DevOps解決上下文切換的不利影響
在計(jì)算系統(tǒng)中，上下文切換發(fā)生在：
操作系統(tǒng)保存一個(gè)應(yīng)用程序線程的狀態(tài)，停止線程并恢復(fù)其他線程的狀態(tài)（之前停止線程），使其他線程恢復(fù)執(zhí)行。
上下文切換管理的開(kāi)銷(xiāo)，發(fā)生在處理狀態(tài)的保存和恢復(fù)，這個(gè)過(guò)程會(huì)對(duì)操作系統(tǒng)產(chǎn)生負(fù)荷，并影響應(yīng)用程序的性能。
在博客使用DevOps解決上下文切換的不利影響中，CERT研究員Todd Waits描述了如何使用DevOps改善負(fù)面影響，減少項(xiàng)目之間的“上下文切換”對(duì)軟件工程團(tuán)隊(duì)效率的影響。
以下為摘錄:
Quality Software Management: Systems Thinking?, 作者在這本書(shū)中討論了，上下文切換的概念是如何適用于一個(gè)工程團(tuán)隊(duì)。
從人力勞動(dòng)力的角度來(lái)看，上下文切換是一個(gè)項(xiàng)目停止工作的過(guò)程，并在不同的項(xiàng)目上完成不同的任務(wù)后，將其重新?lián)炱饋?lái)。就像計(jì)算機(jī)系統(tǒng)一樣，在多個(gè)項(xiàng)目之間進(jìn)行上下文切換時(shí)，團(tuán)隊(duì)成員通常會(huì)產(chǎn)生開(kāi)銷(xiāo)。
當(dāng)團(tuán)隊(duì)成員被分配到多個(gè)項(xiàng)目時(shí)，上下文切換通常會(huì)發(fā)生。上下文切換的合理理由是：
邏輯上來(lái)講，為團(tuán)隊(duì)成員分配項(xiàng)目任務(wù)，比為每個(gè)項(xiàng)目分配專用資源更省時(shí)省力。
這似乎是合理的假設(shè)，將一個(gè)人的精力平分，對(duì)每個(gè)項(xiàng)目，兩者之間的項(xiàng)目收益率百分之50。
此外，如果一個(gè)團(tuán)隊(duì)成員只在一個(gè)單獨(dú)的項(xiàng)目中，如果這個(gè)項(xiàng)目正在等待處理某些事情，比如等待書(shū)面工作審批、審查等，該小組成員將是空閑的，沒(méi)有充分利用。
使用我們計(jì)算系統(tǒng)的隱喻，任務(wù)之間的切換類似多線程概念，如果一個(gè)線程因?yàn)槟承┦虑樽枞?，其他線程可以執(zhí)行其他工作，而不是等待第一個(gè)線程直到恢復(fù)。
如果所有的工作只分配給第一個(gè)線程，進(jìn)展很慢。雖然多線程在計(jì)算系統(tǒng)中很合理，問(wèn)題是，人類并不總是能很好分配精力。因此效率會(huì)在上下文切時(shí)損失，生產(chǎn)力可能會(huì)在精力分散在更多的項(xiàng)目的時(shí)候下降。
閱讀完整的文章，使用 DevOps 解決上下文切換的不利影響，請(qǐng)?jiān)L問(wèn)
http://blog.sei.cmu.edu/post.cfm/addressing-detrimental-effects-context-switching-devops-064
10.什么是 DevOps？
通常，當(dāng)我們?cè)O(shè)想一個(gè)實(shí)現(xiàn)了 DevOps 的組織，我們可以想象一個(gè)自動(dòng)化運(yùn)轉(zhuǎn)良好的機(jī)器：
基礎(chǔ)設(shè)施配置
代碼測(cè)試
應(yīng)用部署
最終，這些做法的結(jié)果是運(yùn)用DevOps的方法和工具。DevOps適合所有規(guī)模的團(tuán)隊(duì)，從一個(gè)一個(gè)人的團(tuán)隊(duì)到一個(gè)企業(yè)組織。在這篇博文中，什么是DevOps，CERT研究員Todd Waits介紹了DevOps的基礎(chǔ)。
DevOps可以看作是敏捷方法的推廣。它要求掌握相當(dāng)多的知識(shí)和技能，包括一個(gè)項(xiàng)目從開(kāi)始到持續(xù)，到被一個(gè)專門(mén)的項(xiàng)目小組負(fù)責(zé)。組織壁壘必須打破。只有這樣才能有效地緩解項(xiàng)目風(fēng)險(xiǎn)。
以下為摘錄:
然而嚴(yán)格來(lái)說(shuō)，DevOps 并不是持續(xù)集成，交付或部署。
DevOps 的做法能使團(tuán)隊(duì)達(dá)到協(xié)調(diào)，理解必要的自動(dòng)化基礎(chǔ)設(shè)施、測(cè)試和部署。特別是，DevOps 提供了組織如何保證：
不同項(xiàng)目團(tuán)隊(duì)人員之間的合作；
基礎(chǔ)設(shè)施即為代碼；
自動(dòng)化任務(wù)、過(guò)程和工作流程；
監(jiān)控應(yīng)用和基礎(chǔ)設(shè)施。
商業(yè)價(jià)值驅(qū)動(dòng) DevOps 的發(fā)展。如果沒(méi)有 DevOps 的心態(tài)，組織經(jīng)常發(fā)現(xiàn)他們的運(yùn)維、開(kāi)發(fā)和測(cè)試團(tuán)隊(duì)，目光短淺，只致力于創(chuàng)建方便自己的基礎(chǔ)設(shè)施、測(cè)試套件或產(chǎn)品增量。
一旦一個(gè)組織打破了這些孤島，把這些領(lǐng)域的專業(yè)知識(shí)整合起來(lái)，就可以把重點(diǎn)放在共同致力于提供商業(yè)價(jià)值的基本目標(biāo)上：
組織良好的團(tuán)隊(duì)會(huì)發(fā)現(xiàn)（或創(chuàng)建）工具和技術(shù)，使他們的組織實(shí)踐 DevOps。每個(gè)組織都是不同的，有不同的需求，不同的但是必須滿足的需求。
DevOps 的關(guān)鍵，并不是一個(gè)殺手級(jí)的工具或腳本，而是合作文化和傳遞價(jià)值的終極承諾。
閱讀完整的，什么是DevOps，請(qǐng)?jiān)L問(wèn)
https://blog.sei.cmu.edu/post.cfm/what-is-devops-324
說(shuō)明
每?jī)芍?，SEI 會(huì)發(fā)布一篇新的博客，為那些嘗試采用 DevOps 的組織提供指南，實(shí)用的建議和教程。我們歡迎您對(duì)本系列文章提供反饋，以及對(duì)未來(lái)內(nèi)容的建議。請(qǐng)?jiān)谙旅娴脑u(píng)論部分反饋意見(jiàn)。
? http://en.wikipedia.org/wiki/Melvin_Conway
? http://en.wikipedia.org/wiki/Conway%27s_law
? http://blog.sei.cmu.edu/post.cfm/devops-agile-317
? https://www.pagerduty.com/blog/what-is-chatops/
? http://www.newmediacampaigns.com/blog/matching-development-production-environments
? http://www.amazon.com/Quality-Software-Management-Systems-Thinking/dp/0932633722
如何一起愉快地發(fā)展
第三十六屆CIO班招生
國(guó)際CIO認(rèn)證培訓(xùn)
首席數(shù)據(jù)官（CDO）認(rèn)證培訓(xùn)
責(zé)編：content
免責(zé)聲明：本網(wǎng)站（http://www.www.gypb.net/）內(nèi)容主要來(lái)自原創(chuàng)、合作媒體供稿和第三方投稿，凡在本網(wǎng)站出現(xiàn)的信息，均僅供參考。本網(wǎng)站將盡力確保所提供信息的準(zhǔn)確性及可靠性，但不保證有關(guān)資料的準(zhǔn)確性及可靠性，讀者在使用前請(qǐng)進(jìn)一步核實(shí)，并對(duì)任何自主決定的行為負(fù)責(zé)。本網(wǎng)站對(duì)有關(guān)資料所引致的錯(cuò)誤、不確或遺漏，概不負(fù)任何法律責(zé)任。
本網(wǎng)站刊載的所有內(nèi)容（包括但不僅限文字、圖片、LOGO、音頻、視頻、軟件、程序等）版權(quán)歸原作者所有。任何單位或個(gè)人認(rèn)為本網(wǎng)站中的內(nèi)容可能涉嫌侵犯其知識(shí)產(chǎn)權(quán)或存在不實(shí)內(nèi)容時(shí)，請(qǐng)及時(shí)通知本站，予以刪除。
搶沙發(fā)
