Configuring Build Steps
When creating a build configuration, it is important to configure the sequence of build steps to be executed.
Build steps are configured on the Build Steps section of the Creating and Editing Build Configurations page: the steps can be auto-detected by TeamCity or added manually.
Each build step is represented by a Build Runner and provides integration with a specific build or test tool. You can add as many build steps to your build configuration as needed. For example, call a NAnt script before compiling VS solutions.
Build steps are invoked sequentially.
The decision whether to run the next build step may depend on the exit status of the previous build steps and the current build status.
The build step status is considered failed if the build process returned a non-zero exit code and the Fail build if build process exit code is not zero build failure condition is enabled (see Build Failure Conditions); otherwise build step is successful.
Note that the status of the build step and the build can be different. A build step can be successful, but the build can be failed because of another build failure condition, not based on the exit code (like failing a test or something else). On the other hand, if a build step has failed, the build will be failed too.
Execution policy
You can specify the step execution policy via the Execute step option:
Only if build status is successful - before starting the step, the build agent requests the build status from the server, and skips the step if the status is failed.
If all previous steps finished successfully - the build analyzes only the build step status on the build agent, and doesn't send a request to the server to check the build status.
Even if some of previous steps failed: select to make TeamCity execute this step regardless of the status of previous steps and status of the build.
Always, even if build stop command was issued: select to ensure this step is always executed, even if the build was canceled by a user. For example, if you have two steps with this option configured, stopping the build during the first step execution will interrupt this step, while the second step will still run. Issuing the stop command for the second time will result in ignoring the execution policy: the build will be terminated.