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.
h1. {anchor:run proof build}Run proof build
After proof build has been [set up|Set Up Proof Build] by your administrators, you may run proof build to make sure that you will not commit bad code into your SCM. However there are some other things need to be done at your side before you can run proof build:
# *Install user agent*
User agent need to be installed on user's computer and connect to QuickBuild server in order to run proof build. When a proof build is running, QuickBuild contacts the user agent to collect uncommitted changes to server. Make sure the administrator has authorized you the [permission to run user agent|Other Permissions#allow user agent] and then follow [this guide|User Agent Installation Guide] to install user agent.
# *Define user attributes in the user agent*
Some user attribute might need to be defined in your user agent in order to perform proof builds. It depends on how your administrator set up the proof build, please contact him/her on what user attributes need to be defined. User attributes can be defined following [this guide|Manage User Agent#define user attribute].
After you complete the above steps, you can trigger proof builds in related proof build configurations just like triggering other builds.
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.
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.
h1. {anchor:run proof build}Run proof build
After proof build has been [set up|Set Up Proof Build] by your administrators, you may run proof build to make sure that you will not commit bad code into your SCM. However there are some other things need to be done at your side before you can run proof build:
# *Install user agent*
User agent need to be installed on user's computer and connect to QuickBuild server in order to run proof build. When a proof build is running, QuickBuild contacts the user agent to collect uncommitted changes to server. Make sure the administrator has authorized you the [permission to run user agent|Other Permissions#allow user agent] and then follow [this guide|User Agent Installation Guide] to install user agent.
# *Define user attributes in the user agent*
Some user attribute might need to be defined in your user agent in order to perform proof builds. It depends on how your administrator set up the proof build, please contact him/her on what user attributes need to be defined. User attributes can be defined following [this guide|Manage User Agent#define user attribute].
After you complete the above steps, you can trigger proof builds in related proof build configurations just like triggering other builds.
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.