您是否負責將代碼部署到實時環境？

Question

...或者您是否必須通過其他人（管理服務器的人）才能部署您的代碼？

我瞭解不讓所有人登錄到實時生產服務器的政策，但我希望能夠在我的代碼，數據庫和文件生效後訪問我的代碼。

對其他人來說如何？

Answer 1

擁有配置管理組或開發組以外的其他人將代碼部署到生產環境具有優勢。其中大部分有助於強化版本的嚴格和審計跟蹤。理想的配置管理團隊應該通過腳本釋放代碼。該腳本從代碼存儲庫中取出某個標記，並釋放到某個服務器。這樣做可以減少一路上的錯誤。

我認爲開發團隊應該只讀取生產數據的權限，並且能夠看到任何日誌文件。這允許更容易地調試問題。如果新版本的代碼還需要數據庫更新，那麼配置管理團隊也應當通過腳本部署這些更改。

Answer 2

這一切都取決於公司有什麼程序。有些比其他更靈活。我們的組織正在擺脫有權訪問生產環境的開發人員。現在，所有事情都必須遵循QA過程，然後是操作（負責部署和維護代碼）。我想你會以較少的事件結束，但是會延長bug修復時間。

Answer 3

在我簽約的最後一個地方，有一組特定的人負責生產服務器上的部署和配置。

你所有的代碼都必須簽入到vcs中，這是他們獲得部署代碼的地方。因此，只要代碼生效，您就無法「訪問」對代碼進行更改。除非是緊急部署，否則他們每週部署兩次新/更改的代碼。

Answer 4

我今天剛剛部署了一些活動環境。我也可以訪問實時數據庫。

這已被認爲會導致過去史詩般的失敗。有時候，有人在生產環境而不是開發環境中放了一張表。但是，我發現另一個人在發佈時沒有什麼優勢，特別是當他不熟悉這個軟件的時候。

Answer 5

理想的釋放過程流程如下（在我的小世界）：

1. 發展信封，其中測試人員進行測試（你上的代碼，並做你的測試）
2. 測試信封（實時數據 - 也可能是你）
3. 在這個階段，它可以直接生活，或釋放到另一個測試場，你可以讓用戶測試它。

取決於你的公司有多嚴格，開發者可能會或可能不能訪問實時版本，特別是如果它是一家大公司。

Answer 6

每個環境都略有不同。相比之下，你必須決定什麼對你有用。亞馬遜例如使他們的開發人員擁有他們自己的代碼，這是一些開發人員所憎惡的，但它是該環境的一個功能，可以使錯誤數量保持在較低水平（您上次在amazon.com上看到錯誤的時間是什麼時候？）。

其他人希望獲得更嚴格的QA流程，以便創建一個運營部門來照顧部署，但我發現他們傾向於在公司中營造一種消極氣氛：他們通過證明他們的角色而獲得獎勵，這需要指出支持世界上的壞事。如果開發者擅長工作，如果他們的薪酬與績效有任何關係，怨恨就會蔓延開來。個人而言，我傾向於照顧整個堆棧，但越來越多地轉向提供商，這讓我越來越不用擔心硬件（EC2，Heroku等），並更多地關注功能。應用。我個人喜歡擁有代碼和錯誤，因爲這意味着我明顯有動機去保持錯誤票 - 每張開放票都是延遲我想要工作的新功能。

各自爲妙。

Answer 7

上面提到的開發和測試環境的答案。擁有專用的獨立構建服務器也是非常重要的，它不用於開發。它從存儲庫中提取源代碼，編譯並創建分發（在Java世界中的EAR或WAR文件），然後部署到測試環境等。

該構建服務器還可以託管CI環境並定期執行自動日常構建。