In my last post, we created a new project in Visual Studio Online and checked in the initial creation of the associated Visual Studio project and solution, associating with a task in the process. Now it's time to create a new build definition so that Visual Studio Online will start a build automatically anytime a developer checks in updated code.
With your solution open in Visual Studio 2013, go to the Team Explorer view and hit the "Builds" button. You'll see that no builds have been performed and that no definitions currently exists. Select the "New Build Definition" link to open up the wizard for configuring a new automated build. On the first tab, provide a name for the build, along with a helpful description. In large and complex projects you can wind up with many useful build definitions, so these fields are very important.
The "Trigger" tab is very simple, but most important. This setting dictates when the build will be performed. Each of the options can be very useful in different situations. You might use a manual trigger for a production build, or a scheduled build to deploy code into a staging environment on a nightly basis. For now, we're assuming we're just getting started on a new project with multiple developers. With lots of code being checked in by different people on a regular basis, the "continuous integration" trigger is a godsend. Building the project every time a developer checks something in ensures that build errors will be caught right away, before other developers might grab the latest code and hinder their own work. Having TFS perform the build operations automatically obviously saves each developer a lot of time, and ensures that the process is always followed.
The "Source Settings" tab enables you to manage which folders from source control will be part of the build - the default settings should usually be fine here. On the "Build Controller" tab, select "Hosted Build Controller" to have Visual Studio Online perform the build on a remote server. Select "Copy build output to the server" so that other developers can easily download the compiled code from the server. The "Process" tab is significant in that it provides different options based on the type of build/deployment we need to do. For a standard Visual Studio 2013 project, we'll select the "TfvcTemplate.12.xaml" template. Finally, the "Retention Policy" tab allows us to set how long the build artifacts should be kept, but the default settings are usually fine here as well.
Once we've completed the configuration, it's time to save the new build definition and test it out! Even though we selected the "continuous integration" trigger, we can still start the build manually as well. Back on the Builds tab of Team Explorer, we now see our new build definition listed under "All Build Definitions." Right-click on it and select "Queue New Build..." The settings should be good to go and the build should complete (hopefully) successfully. As soon as the build is queued, it will show up under "My Builds" in Team Explorer - you can double-click it to view detailed progress - and also on the "Build" tab of your VSO project site. Once the build is done, you can download the output as a ZIP file from the website - how cool is that?!
Getting a continuous integration build setup is a huge step forward for many development teams. Ensuring that the build is successful after each check-in helps maintain quality. Next, we'll take this to the next level by including the execution of unit tests in our build definition to ensure that the code doesn't just build, but actually works!
No comments:
Post a Comment