通過維基百科進行閱讀我遇到了敏捷開發中的Sprint概念。根據我的理解，Sprint是一組開發人員編寫一定數量的功能時，一旦這些功能被編程，它們就被打包併發送到客戶端，然後下一個sprint開始並且另一組功能被編碼並運送出去等等on ...如何迭代地部署軟件？
我想知道客戶端如何安裝這些功能，以便它們成爲包含以前功能的軟件的一部分，編譯後的代碼是否以客戶端安裝的修補程序的形式發送？整個應用程序是否會重新編譯，客戶端是否使用更新後的功能重新安裝應用程序？使用某種框架設計的應用程序是否可以簡單地將新功能插入到當前安裝的應用程序中？它是怎麼運行的？
每個衝刺不是實際上是部署。它們是可部署的，但並不總是部署。
「整個應用程序是否得到重新編譯，客戶端是否使用更新後的功能重新安裝應用程序？」
當然。這是一個新的版本。市場營銷經常干預和捆綁幾個衝刺到一個大包裝釋放。
「是使用某種框架的設計應用了新的功能，可以簡單地插入到當前安裝的應用程序嗎？」
很少。
衝刺的定義通常是基於優先級實現功能的固定時間量;所以時間是固定的，內容是可變的。
衝刺的想法是提供潛在的可交付代碼;這並不意味着每個版本都必須部署在客戶端。通常還有另一個過程，例如可以進行驗證和部署。或2/3/4 sprint中的每1個都是發佈衝刺。
這個想法是，在每次衝刺結束時，你應該完全和完全地部署（實際上，甚至在衝刺中）。這個版本將減少功能，但它應該在部分實現的限制內完全可用。客戶通常不涉及Q/A部門（如果您在「最終發佈前」有一個專門的部門）。誰介入是：
如果客戶想看到的東西，你隨時準備向他展示。這會讓他感興趣，給他一種進步感和安全感（你正在做一些事情，他可以看到進步的改進），最終他可以爲你提供有用的反饋。
我工作的公司（以及我認識的大多數其他敏捷公司）都在web開發領域工作，這些問題都不在意。你的系統管理員在每次衝刺結束時都會在網絡服務器上部署（理論上）。在實踐中，我說我們部署了其他所有完成的衝刺。