在 CI中如何縮短build的時間以增快feedback
from Chapter 4 Building Software at Every Change, Continuous Integration
在CI(Continuous Integration)中, feedback的時間是非常重要的. 在這段時間中, 產生build的時間所佔的比例是非常大. 因此如何縮短build產生的時間, 是run CI的人重要的課題
在CI一書中, 它將build分成三個種類
A. Private Build
- A developer will run a private build prior to committing code to the repository.
- By running a private build, you integrate your changes with the last changes available in the version control repository.
B. Integration Build
- An integration build integrates changes committed to the repository by the team against the mainline (also known as the head or trunk).
- Ideally, an integration build should run on a separate, dedicated machine.
C. Release Build
- A release build readies the software for release to users.
- One of the goals of CI is to create deployable software.
- A release build may occur at the end of an iteration or some other milestone, may include more extensive performance and load tests, and must include any acceptance tests.
當你分好類後, 你可設定不同執行方式來產生build
Build Type Build Mechanism
=========== ===============================================
Private On-demand
Integration On-demand, poll for changes, scheduled, event-driven
Release On-demand, scheduled
此外Flower還提出stage build 的觀念, 所謂stage build 就是 different types of builds that can be run as part of an integration build. 所以他將 build分成兩類:
A. Lightweight build (commit build)
(1) description
-You first run an initial integration “commit” or lightweight build that integrates the software components and runs unit tests to root out any obvious problems.
(2) possible activies
Compile Source Code, Integrate Database, Run Tests, Run Inspections, Deploy Software
B. Heavyweight build (secondary build)
(1) Description
- After this lightweight build is successful, a more exhaustive integration build is run to include component tests or system tests, inspections, and deployment.
- This supports the practice of “fail builds fast,” described earlier in this chapter.
(2) possible activies
Longer Running Tests(Component, System, Functional, Performance), Code Coverage
最後還有一招"Fail Builds Fast"
(1) Good builds know how to fail fast. It is annoying to fail after so many other portions of the build have passed, and you are losing precious time targeting the failed targets.
(2) It all depends on what is more likely to fail most often on a particular project.
from Chapter 4 Building Software at Every Change, Continuous Integration
在CI(Continuous Integration)中, feedback的時間是非常重要的. 在這段時間中, 產生build的時間所佔的比例是非常大. 因此如何縮短build產生的時間, 是run CI的人重要的課題
在CI一書中, 它將build分成三個種類
A. Private Build
- A developer will run a private build prior to committing code to the repository.
- By running a private build, you integrate your changes with the last changes available in the version control repository.
B. Integration Build
- An integration build integrates changes committed to the repository by the team against the mainline (also known as the head or trunk).
- Ideally, an integration build should run on a separate, dedicated machine.
C. Release Build
- A release build readies the software for release to users.
- One of the goals of CI is to create deployable software.
- A release build may occur at the end of an iteration or some other milestone, may include more extensive performance and load tests, and must include any acceptance tests.
當你分好類後, 你可設定不同執行方式來產生build
Build Type Build Mechanism
=========== ===============================================
Private On-demand
Integration On-demand, poll for changes, scheduled, event-driven
Release On-demand, scheduled
此外Flower還提出stage build 的觀念, 所謂stage build 就是 different types of builds that can be run as part of an integration build. 所以他將 build分成兩類:
A. Lightweight build (commit build)
(1) description
-You first run an initial integration “commit” or lightweight build that integrates the software components and runs unit tests to root out any obvious problems.
(2) possible activies
Compile Source Code, Integrate Database, Run Tests, Run Inspections, Deploy Software
B. Heavyweight build (secondary build)
(1) Description
- After this lightweight build is successful, a more exhaustive integration build is run to include component tests or system tests, inspections, and deployment.
- This supports the practice of “fail builds fast,” described earlier in this chapter.
(2) possible activies
Longer Running Tests(Component, System, Functional, Performance), Code Coverage
最後還有一招"Fail Builds Fast"
(1) Good builds know how to fail fast. It is annoying to fail after so many other portions of the build have passed, and you are losing precious time targeting the failed targets.
(2) It all depends on what is more likely to fail most often on a particular project.
全站熱搜
留言列表
