If you are new to Continuous Integration feel free to check our this in-depth article by Martin Fowler.
We have a lot to cover so let's start.
Preparing the source
The source code of your Sitefinity project should be available through some kind of version control system. Visual Studio Team Services supports Git, Team Foundation, and Subversion so you are pretty much covered.
You might also consider switching to Nuget packages for all Sitefinity dependencies. This has many benefits and the whole process is illustrated in our post Migrate Sitefinity assembly references from bin to NuGet packages.
Creating a Visual Studio Team Services Project
There are numerous continuous integration platforms out here. For today's exercise we are going to use Visual Studio Team Services (VSTS). This is one of the most advanced platforms out there that can suit the needs of pretty much every project.
If you haven't signed up yet you can do it at https://www.visualstudio.com/team-services/.
Once you have an account, go to your dashboard and choose to create a new project.
Choose an appropriate name for your project. You can safely ignore the remaining settings and use the defaults.
Your project should be ready now. Visual Studio Team Services (VSTS) covers every aspect of project management and there are a lot of areas to explore. For the time being let's focus on the task at hand and go to the Build & Release tab.
Creating a build definition
In a nutshell, build definitions are recipes that specify what commands should be executed in order for you software to be built. Do not get discouraged if you are new to CI and creating builds - VSTS has a very intuitive UI for configuring everything you need.
Click on New definition to create a new build. VSTS has an array of build templates but let's choose an empty one so that we can go through the whole process.
On the next step you have to choose a name for your build and something called an agent. Choose Hosted as agent. Now we are ready to start putting together the build process.
Build definitions are composed of smaller items called tasks which are usually executed in order. By default, you will have the first task already defined. This task is responsible for getting the source code from your repository.
Setting up the source
Click on Get sources to configure the source. Since my own source code is on Github I have used the Github integration to give VSTS access to my repository.
If you are using Nuget, we should introduce a step to restore Nuget packages. Feel free to checkout our article on switching to Nuget packages for your Sitefinity project.
Click on Add Task, search for Nuget, and add the Nuget task to the definition. Make sure that you check "Feeds in my Nuget.config" and input the path to the Nuget config - should be "./NuGet.Config"
Ultimately, the task should look like this:
Npm Install (Optional)
Your project might be using some node packages and they also need to be restored.
Click to add a new task, search for npm, and add the npm task. The only change that might be needed for this task is the working folder setting. If your package.json is not in the root, just input the correct folder.
Here is how the config should look like:
Search for Gulp, and add it to the build process. Now we need to do a bit more work - first you need to specify the path to your gulp file and then the Gulp task that should be executed.
The task should look similar to this:
Visual Studio Build
It is time for the final and most important task. So far the build process is configured to retrieve the source code, restore any packages, and run a Gulp build. What is left is building the Sitefinity solution - we do this with the help of Visual Studio Build.
Add a new task, search for Visual Studio Build, and add it to the build.
The default settings are as good as it gets - the platform will look for any .sln files and build them. If you would like to build just a single solution, make sure that you specify the correct path.
Take a note of the Platform and Configurations inputs. They are empty by default and that needs to be fixed. Those inputs will allow us to control what kind of builds are being produced. For example, we can choose to trigger a Release or Debug build. Use $(BuildPlatform) and $(BuildConfiguration) for Platform and Configuration respectively.
Here is how the task should be configured:
As mentioned, this is the final build task. At this point the build definition should look like this:
Turn On Continuous Integration
The build process is now ready but currently it can be only triggered manually. Continuous integration is all about getting feedback after every code change.
To enable this feedback loop, navigate to the Triggers tab and enable the trigger. Here you can configure how the build is triggered. Again, the default setting should be alright.
Now whenever something new has been pushed to the repository, a build will be triggered automatically.
Setting up build variables
Build variables allow you to pass information down to the build pipeline.
Remember the two weird settings that were used for Configuration and Platform in the Visual Studio Build step? What we will do now is create these variables which will allow us to control control the platform and configuration of our builds.
To create the variables, navigate to the Variables tab and add two new variables with their respective names and values, as shown in the image below.
Make sure that you check "Settable at queue time" - this will allow you to override the default values whenever you are triggering a build.
There are various other scenarios where variables come in handy and I would recommend reading up on build variables whenever you have the chance.
Our build definition is now ready, let's test it.
Triggering a build
We now have a basic continuous integration setup. Apart from having automatic builds, builds can be triggered manually. Let's do that to verity that everything is working as expected.
Go to the Build & Release tab and select your build. Clicking the big blue button (Queue new build) will trigger a build. You will be redirected to a new page where live information about the build is being displayed.
Hopefully, all tasks will execute without errors and you will have your first successful Sitefinity build with Visual Studio Team Services.
The build that has been created provides a solid foundation that you can easily build upon and add features like running test, automatically deploying to Windows Azure, or anything else that your team needs.
We will take a closer look at those other enhancements in the articles to come.
As always, leave any comments, questions, or suggestions in the section below.