h1. Introduction
Usually developers commit their code after they build and unit test their code successfully in their IDE. However, this has some limitations:
* Developer's computer may not have the same environment as the test server. The new code works well on developer's computer, but may fail on the test server.
* Tests on the server might be more thoroughly, for example automated GUI tests may be executed and all dependent components might be tested as well. The developer's computer may not have such tool(s) installed.
* The product may consists of components that need to be built and tested on different platforms.
* The test server might be much more powerful, or it may utilize build grid feature to run tests in parallel on multiple agents.
QuickBuild introduces the concept of proof build to remove such limitations:
# The developer runs a proof build before committing their changes to SCM.
# QuickBuild collects uncommitted changes from developer's computer to patch code checked out from SCM, and builds/tests them on test server.
# If the build/test is successful, QuickBuild can optionally checkin the changes on behalf of the developer automatically.
# If the build/test fails, developer fixes the error locally and re-runs the proof build until the build is successful.
For distributed version control systems, the process will be:
# The developer runs a proof build before pushing local commits to the central repository.
# QuickBuild collects local commits from developer's local repository to patch code pulled from central repository, and builds/tests them on test server.
# If the build/test is successful, QuickBuild can optionally push the local commits on behalf of the developer automatically.
# If the build/test fails, developer fixes the error locally and re-runs the proof build until the build is successful.
h1. Run proof build
Proof build support needs to be enabled at repository level before you can run a proof build. Refer [here|set up proof build] on how to set up proof build.
h1. Local changes
A local changes tab will appear after a proof build finishes. It is used to display uncommited changes collected from user's desktop. Just like in [build changes|Working with Changes] tab, you can view and diff source files.
!local-change.png!
Local change tab can be a good place to do code review: you submit your uncommited changes to QuickBuild to do a proof build. If the proof build is successful, it means that your change has at least passed the build process, then you send link of the proof build to other people for review before commit your changes.
For distributed version control systems, the local changes tab displays local commits picked up for proof build.
Usually developers commit their code after they build and unit test their code successfully in their IDE. However, this has some limitations:
* Developer's computer may not have the same environment as the test server. The new code works well on developer's computer, but may fail on the test server.
* Tests on the server might be more thoroughly, for example automated GUI tests may be executed and all dependent components might be tested as well. The developer's computer may not have such tool(s) installed.
* The product may consists of components that need to be built and tested on different platforms.
* The test server might be much more powerful, or it may utilize build grid feature to run tests in parallel on multiple agents.
QuickBuild introduces the concept of proof build to remove such limitations:
# The developer runs a proof build before committing their changes to SCM.
# QuickBuild collects uncommitted changes from developer's computer to patch code checked out from SCM, and builds/tests them on test server.
# If the build/test is successful, QuickBuild can optionally checkin the changes on behalf of the developer automatically.
# If the build/test fails, developer fixes the error locally and re-runs the proof build until the build is successful.
For distributed version control systems, the process will be:
# The developer runs a proof build before pushing local commits to the central repository.
# QuickBuild collects local commits from developer's local repository to patch code pulled from central repository, and builds/tests them on test server.
# If the build/test is successful, QuickBuild can optionally push the local commits on behalf of the developer automatically.
# If the build/test fails, developer fixes the error locally and re-runs the proof build until the build is successful.
h1. Run proof build
Proof build support needs to be enabled at repository level before you can run a proof build. Refer [here|set up proof build] on how to set up proof build.
h1. Local changes
A local changes tab will appear after a proof build finishes. It is used to display uncommited changes collected from user's desktop. Just like in [build changes|Working with Changes] tab, you can view and diff source files.
!local-change.png!
Local change tab can be a good place to do code review: you submit your uncommited changes to QuickBuild to do a proof build. If the proof build is successful, it means that your change has at least passed the build process, then you send link of the proof build to other people for review before commit your changes.
For distributed version control systems, the local changes tab displays local commits picked up for proof build.