Getting Started with Sitecore and Microst Azure Apps – Part 1 – One-Click Azure PaaS Deployment

Sitecore Web Content Management System (WCMS) has recently release a version which supports deploying Sitecore WCMS as Platform as a Service (PaaS). As a passionate Sitecore technologist, this is great news and I am pretty excited about it.

Pieter Brinkman from Sitecore has done a great job explaining the benefits of using Microsoft Azure Web Apps and I think in few years from now, everyone will be using Microsoft Azure as their preferred hosting option.

In this post, I will post a short video screen cast of showing how easy it is to take advantage of this new offering from Sitecore and get an instance of Sitecore up and running in few minutes.

So if you never looked into Microsoft Azure web apps or didn’t get time to do it yourself, this video is for you.

 

Once the deployment is finished, you will see the following services within the resource group:

  • CM App Service Plan & CM Web App
  • CD App Service Plan & CD Web App
  • SQL Server with Core and Master DB
  • SQL Server with Web DB
  • Application Insights (used for logging exceptions and much more)
  • Azure Search
  • Redis Cache

In technical Sitecore terms, this is called XM1 configuration, where Sitecore is deployed in CMS-only mode. You can use this deployment if you are not planning to use analytics and marketing features of Sitecore. An overview of this deployment topology is shown below:

In the next post, I will show how can we use ARM Templates, Sitecore Azure Toolkit and PowerShell to do Sitecore deployments on Microsoft Azure. The ARM templates provides more flexibility and control over the deployment topology.

Stay tuned.

Thanks

Naveed

Sitecore DevOp Series – Part 8 – Setup Slack Notifications with TeamCity and Bitbucket

This is last part of the Sitecore DevOp series. Previously, we have installed a local instance of the Sitecore site, configured VS project, configured TDS, configured Sitecore Glass added our project to source control , congured DB and QA servers and configured CI server. The blog series is aimed at newer audience and developers who are setting up CI for the first time.

There are 2 processes that you need to track during the build:

  • Code submissions (check-ins)
  • CI build events (start/stop/failures)

By default, we can use emails as notifications whenever CI server triggers a build or when source control detects a check-in, but in my opinion, this is not the most effective way. Depending upon your team size, there may be many check-ins every day, and many CI builds. If you start getting hundreds of emails everyday, you will simply create a rule/folder where all such emails will be directed and forgotten.

Also, not all of your team members will receive such notifications emails and you still have to send a ‘pre deployment’ email to notify team and ‘post deployment’  email to confirm that deployment has ended.

If you are a team lead or QA or PM, I am sure you would have asked or heard questions like these:

‘When are we deploying latest build on QA?’

‘Is our latest build finished on QA?’

‘What all did we deploy? 

… and so on.

There are better communication tools out there like Slack or HipChat. You can integrate either of them or another messaging tool of your choice. Personally, I like Slack and will be discussing how to integrate Slack with our TeamCity server and BitBucket project in this blog post.

Step 1: Create a Slack Channel

If you don’t have a Slack account, create a free one. Then create a free Slack channel for your project, invite all team members and also create 2 open public channels for incoming notifications:

  • #bitbucket
  • #teamcity

slack-12

Step 2: Configure TeamCity for Slack Notifications

Navigate to Apps and Integration section and click on the link

slack-1

 

Step 3: Generate a webhook for CI server

Within the slack admin interface, search for incoming hooks:

slack-2

Select ‘Incoming Webhook’ and then select the one of your channel:

slack-3

Once you click Add Incoming WebHooks integration, it will generate a unique Webhook URL, copy this URL for later.

slack-4

Step 4: Install a Slack plug-in for TeamCity

Download a TeamCity plug-in for slack notifications and install it as per the instructions on the documentation

slack-5

There is no admin interface for setting up the incoming hook for the plug-in as of now. So you have to RDP and update a config settings to the relevant web hook

<slackNotifier postSuccessful="true" postFailed="true" postStarted="true">
 <slackDefaultChannel>#teamcity</slackDefaultChannel>
 <slackPostUrl>https://hooks.slack.com/services/xxxxxxx/yyyyyy</slackPostUrl>
 <slackLogoUrl>http://build.tapadoo.com/img/icons/TeamCity32.png</slackLogoUrl>
 </slackNotifier>

Once it is installed correctly, for every build start, build finished and build failed you and every team member will get a notification in the channel.  How cool is that 🙂

slack-6

Step 6: Generate a webhook for BitBucket

Slack is also very friendly with BitBucket source control. Search for a BitBucket integration on Slack and generate a Webhook URL for your #bitbucket channel

slack-10

Step 7 : Configure Bitbucket

Within your bitbucket admin interface for the project, navigate to settings and add a new webhook for the channel. Copy/paste the URL that was generated.

slack-9

Once it is done, commit and push some changes, you will start getting notifications in Slack!

slack-11

So now every time someone in your team is going to do a check-in, you and all your team will get a notification. Install Slack for mobile and desktop and keep tracking those notifications.

With this blog post, we have come to the end of the Sitecore DevOp Series.

Thanks for the reading the blog post and the series, I hope it will benefit the Sitecore community. Any comments feedback will be appreciated.

Naveed.

Updated April 2017

My Talk at DC Sitecore User Group

Short video demo

Related Blogs

  1. Part 1 – Continuous Integration – Why your Sitecore project deployments must be automated ?
  2. Part 2 – Setup and Configure Visual Studio Sitecore Project
  3. Part 3 – Setup and Configure TDS
  4. Part 4 – Setup Sitecore Glass
  5. Part 5 – Setup Source Control (Git)
  6. Part 6 – Setup QA Server, DB server and CI server
  7. Part 7 – Setup Continuous Integration using Team City
  8. Part 8 – Setup Slack Notifications with TeamCity and Bitbucket

Sitecore DevOp Series – Part 7 – Setup Continuous Integration using Team City

This is part 7 of the blog series. Previously, we have installed a local instance of the Sitecore site, configured VS project, configured TDS, configured Sitecore Glass added our project to source control and congured DB and QA servers.

I am assuming that you have gone through the previous 6 parts and completed them as this blog post will depend upon them. I am also assuming that you have a brand new CI server with following applications installed:

  1. TeamCity latest stable version
  2. Visual Studio Community Edition
  3. Team Development Server for Sitecore (TDS)
  4. Chocolaty
  5. Git

This is a pretty lengthy blog and contains with lots of screen shots for every step of the TeamCity server configuration. If you get stuck at any point please look at the CI build logs, QA server logs and utilize Google to resolve your errors/issues.

The blog series is aimed at newer audience and developers who are setting up CI for the first time.

Step 1: Create TeamCity Project

Once TeamCity is installed, create your TeamCity project:

tc-1

Once the project is created, you will have the ability to configure it with your source control:

tc-2

Step 2: Configure with Source Control

Select ‘Create build configuration from URL‘ and give the source control URL of your project along with login details.

tc-3

If your connection details are correct, you will see the confirmation screen like below:

tc-4

Step 3:Configure Build Steps

Now its time to configure your build steps. The TeamCity will try to auto-detect your build steps:

tc-5

If everything on the server has been configured correctly, it will configure the VS build step:

tc-6

Step 4: Configure NuGet step and re-order

Create a new step by clicking on ‘Add build step’  and add a ‘NuGet Installer’  step type. Specify the path to the solution:

tc-7

The build steps will be executed in the sequence they are ordered, so you need to re-order them. Click on ‘Reorder build steps‘ and put NuGet installer step before the VS build step:

tc-8

If you are using any front-end frameworks, like Gulp or Grunt, you can also add a step for them using Node.Js as runner type.

Step 5: Configure Parameters

As we have added 2 steps, at this point we should test our CI server with only these 2 steps and try to fix any errors before proceeding further. Before we run the build, we need add some configuration parameters and tell TeamCity to use our QA publish profile so it can correctly transform the config files. The configuration parameters can be added in-line within the build steps but a better way is to add them as system parameters. Navigate to the ‘parameter‘ section to add parameters:

tc-9

By clicking ‘add new parameters‘ a dialog box will show up, you can then add ‘System‘ parameters for your build as shown:

tc-10

Repeat the process of adding new parameters and add all of the following parameters for your initial build. Update the system.username and system.password values relevant to your CI server. The system.PublishProfile should also be updated as per your VS project’s publish profile name:

tc-11

Step 6: Run a Test Build

Click on the ‘Run’ button and test your build for the 2 steps that you have added:

tc-12

I only had 2 steps, but I still got some errors on the first build which I resolved by looking at the ‘Build log‘ (like I missed a file to push to bitbucket and then my password was incorrect). After few attempts, I saw the green tick which was very re-assuring. So if your build fails for the first time, it’s OK, work through the build log and remove errors:

tc-13

Step 7: Configure Sitecore.Ship

As of now, we were only deploying code files from VS with our 2 steps. But we also want to deploy our Sitecore Items generated through TDS update packages. By default, you can use TDS to deploy .update packages, however, there are other alternatives too. I am going to use an open-source module Sitecore.Ship which deploys update packages over http requests. The module should be configured as NuGet package with you main web project:

tc-14

Once you install this, you will notice that there are some changes in your web.config files as well, check-in all of your changes and push them to the server.

Step 8: Configure TDS.Master

The next step is to configure TDS.Master to generate an update package. Navigate to MyProject.TDS.Master project’s properties, make sure the build mode is ‘Release‘ and update the settings as shown below:

tc-15

Once you will build this, it will generate an .update package at a location bin/package_release

Step 9: Add a build step for TDS Master

An update package has been generated, now we want to deploy and publish this package along with our code to the QA server. We will be using curl to post HTTP request for update packages. Chocolatey is a package manager which can give us access to curl through its command line.

The deploy and publish step depends upon some configuration parameters. Navigate to parameters section and add the following configuration parameters:

tc-22

Navigate to the build step section add a ‘command line‘ build step for TDS Master pacakges and enter the value for custom script as shown below: (update the project path relevant to your project)

tc-17

Custom Script:

%curl.path% -i --insecure --show-error --fail --silent --form "path=@MyProject.TDS.Master\bin\Package_Release\MyProject.TDS.Master.update" %deploy.url%

 

Step 10: Run a test build for TDS.Master

There were few tools and configuration were settings introduced in the previous steps and to make sure everything works as expected perform a test build. If it fails, look through the logs and try to resolve issues. Some places where you also want to look are Sitecore Logs (in the data folder) on the QA server and website/temp folder on the QA server.

When I ran the first build, I got 500 error in the TeamCity build log for the TDS.Master deploy step. The error messages within the build log for Sitecore.Ship are not exact messages and may be misleading, you need to check the logs on the QA server for correct messages.

When I checked if Sitecore.Ship is installed and accessible fromm the CI server, I was getting 401 error:

tc-ship-1

and when I checked this from the QA server, I was getting everything is OK

tc-ship-2

When I checked the Sitecore logs on QA server, I got the following message

tc-ship-4

Which meant that I have to update the ‘allowRemote’ settings to ‘true’ in the web.config to allow remote package installation. The feature is disabled by default for security reasons. I also added IP address of the TeamCity server to the whitelist section and made my remote deployments IP protected:

tc-ship-3

Once checked-in and pushed to the server, I got some more errors related to missing folders and permissions.  I was able to resolve them by checking the logs and giving NETWORK SERVICE permissions to the folders.

Eventually, the deploy step succeeded and I was able to see Sitecore.Ship posting my entries from the CI server to the QA server:

tc-ship-5

This is great news, it means that when I check-in TDS items and related code, I do not need a package to update the QA server ‘manually’. I can just run the build and it will pick up the latest changes and deploy them.

Step 11: Configure a TDS publish step

The previous step has only deployed our update package. We also want to publish our package post deployment. We can configure a publish step through curl and Sitecore.Ship

Navigate to the ‘Build Steps‘ section and add another ‘Command Line‘ step for publishing. Add the custom script as shown below:

tc-18

Custom Script:

%curl.path% -i --insecure --show-error --fail --silent --data '' %publish.url%

Run a test build to confirm it is working as expected.

Step 12: Configure TDS.Core and its build Step

One more step is to configure TDS.Core project with TeamCity server. We want our TDS project to generate an .update package for the TDS.Core project.

Navigate to MyProject.TDS.Core project’s properties and update settings as shown below:

tc-19

Then add a ‘command line‘ step in Team City similar to the TDS.Master deploy step with following script (which only changes the path variable)

%curl.path% -i --insecure --show-error --fail --silent --form "path=@MyProject.TDS.Core\bin\Package_Release\MyProject.TDS.Core.update" %deploy.url%

Re-order the steps so you have core packages deploying before the master packages. Your build steps should look like below:
tc-20

Depending upon your project and business requirements, you may want to add more steps like ‘Unit Testing’ or ‘Integration Test’ or other steps.

Step 13: Configure Triggers (Optional)

One optional thing to do is to configure trigger for the QA server, so that every time someone pushes the code to the source control, an automated build is started:

tc-21

This is optional and you shouldn’t be configuring this step for the production environments

More Environments

The blog post only showed how to add build steps for the QA environment, but you may have a UAT environment, a staging environment and a production environment. You can repeat the build configuration process and add more automated deployments for each of your environment.

The steps mentioned here are only an example and meant to provide the basics of setting up CI integrations. Once you get comfortable, you can enhance number of steps and/or use different deployment strategies.

Final Thoughts

As you have seen, it took few blog posts to get the Continuous integration working, but once it is established, it will save you tons of time during the application development and even post-launch. If your organizations sets up projects frequently, the time to setup QA, DB and CI servers and local environments can be further reduced by using standard PowerShell scripts.

One final optional blog post about Slack notifications is coming up next few days and then it will be a wrap.

Thanks.

Related Blogs

  1. Part 1 – Continuous Integration – Why your Sitecore project deployments must be automated ?
  2. Part 2 – Setup and Configure Visual Studio Sitecore Project
  3. Part 3 – Setup and Configure TDS
  4. Part 4 – Setup Sitecore Glass
  5. Part 5 – Setup Source Control (Git)
  6. Part 6 – Setup QA Server, DB server and CI server
  7. Part 7 – Setup Continuous Integration using Team City
  8. Part 8 – Setup Slack Notifications with TeamCity and Bitbucket

Sitecore DevOp Series – Part 6 – Setup QA Server, DB server and CI server

Happy New Year 2017!!!

This is part 6 of the Sitecore DevOp series. Previously, we have installed a local instance of the Sitecore site, configured VS project, configured TDS, configured Sitecore Glass and added our project to source control. In this post we will install blank Sitecore site on QA server and setup QA website’s Web Deploy publish profile with our VS project. The blog series is aimed at newer audience and developers who are setting up CI for the first time.

Assumptions

I am assuming that you have RDP access to at least 3 Windows based server within your local network/organization. From the diagram below, the QA server will host CM and CD part of the website (qa.myproject.local). The DB server will host SQL server and MongoDB databases. The CI server will host the TeamCity server (teamcity.myproject.local). The blog series is based upon Sitecore version 8.2

my-project-qa-setup

This is only a QA setup diagram, for staging and production environments, it is strongly recommended to add separate CD and CM servers.

Step 1 : Configure DB Server

The first step will be to configure the DB Server.

  1. Download and install SQL express
  2. Download and install MongoDB

For compatibility purposes of SQL and MongoDB versions with your version of Sitecore, please check the KB page https://kb.sitecore.net/articles/087164

Setup MongDB to run as Window Service and open the relevant ports from the windows firewall utility on the DB server for incoming and outgoing connections.

Alternatively, if you are new to MongoDB and not sure how to configure and install MongoDB, you can also use mlab free Sandbox environment which gives 500 MB of free storage. You can setup your MongoDB servers following this post and just update the connection strings for the QA server config file.

Step 2 : Install Sitecore Databases

RDP to the DB server and install Sitecore using the official installer. During the wizard steps, select the ‘New Instance‘ option and then select ‘Database Only‘ option:

db-1

Follow the installation wizard as per the installation guide and complete it.At the end, you should have the following 5 SQL databases:

Core, Master, Web, Analytics and Session

db-2

Step 3 : Configure QA Server

RDP to the QA server and using the official installer, select ‘New Instance’ and ‘Client Only’ option:

qa-client-1

Follow the installation wizard and complete all steps. Update your local DNS server or your own hostfile so that http://qa.myproject.local point towards the QA server. Login via the CMS interface using default admin credentials and complete the post-deploy steps from the installation guide.

Step 4: Configure Web Deploy on QA Server

Web Deploy is an IIS extension/utility that provides ability to deploy new updates on the website using IIS only. If your server does not have this utility for IIS, install it via standard installer.

Once installed complete the following steps:

  • Open IIS, navigate to the website which corresponds to http://qa.myproject.local
  • Right-Click on the website and generate WebDeploy Publish Profile

 

qa-client-2

 

  • Select a local computer user like (machinename\WDeployAdmin) and give this user admin rights by making it of the local admin groups.
  • Save the publish profile as a file on the desktop and copy it to your local machine.

As a reference, follow the installation guide.

Publish Profile for QA server

Open the VS project and import the profile for the QA site. You can open the publish profile using notepad and re-name the profile name. Make sure you can validate the connection for the publish profile. If you are getting errors, please resolve them using this post before proceeding further:

qa-client-3

XML transform files for QA profile

Add XML transform files for the new ‘qa‘ publish profile. As a minimum, add transforms for ConnectionStrings.config and Sitecore.config. You will be required to update values for connection strings and dataFolder:

qa-client-6

Try to publish to the QA server via VS project, if everything has been done correctly, you should see the successful message. Navigate to http://qa.myproject.local and ensure everything is correct. If there are errors, resolve them before proceeding further.

qa-client-7

This ensures that Web Deploy is configured correctly and there are no permissions or network issues. This is only the initial part, what we really want to build and deploy from our CI server and not from a local machine of a developer.

Step 5: Setup CI server (TeamCity and Plug-ins)

Assuming it is a brand new Windows server with nothing installed, you need to download and install the following the TeamCity server

  1. TeamCity latest stable version
  2. Visual Studio Community Edition
  3. Team Development Server for Sitecore (TDS)
  4. Chocolaty
  5. Git

All of the above tools have a standard Windows base installer and they follow ‘Click Next’ type wizard to complete. Once all these utilities are installed, we will begin setting up the CI server in next blog post.

Stay tuned.

Thanks

Related Blogs

  1. Part 1 – Continuous Integration – Why your Sitecore project deployments must be automated ?
  2. Part 2 – Setup and Configure Visual Studio Sitecore Project
  3. Part 3 – Setup and Configure TDS
  4. Part 4 – Setup Sitecore Glass
  5. Part 5 – Setup Source Control (Git)
  6. Part 6 – Setup QA Server, DB server and CI server
  7. Part 7 – Setup Continuous Integration using Team City
  8. Part 8 – Setup Slack Notifications with TeamCity and Bitbucket

Sitecore DevOp Series – Part 5 – Setup Source Control (Git)

This is part 5 of Sitecore DevOp series. Previously, we have installed a local instance of the Sitecore site, configured VS project, configured TDS, configured Sitecore Glass for auto-code generation.

In this blog, we are going to add our VS project to a source control. As a developer or as an organisation you have many options available to select your source control like SVN, TFS, or Git . The choice of source control depends upon your business requirements or your client’s requirements.

For the purpose of the blog, I will be using bitbucket.org with repository type as Git. The blog series is aimed at newer audience and developers who are setting up CI for the first time.

Assumptions

I am assuming that the person reading this post has never used Git or Bitbucket before, so I will be doing a step-by-step description.  If you have not used Git before please spend 1 hour reading about it’s basic operations and install a Git client like Tortoise Git or Source Tree. I will be using Tortoise Git for the blog post. If you are a git pro, you can ignore this blog post as all we are doing in the post is setting up our project with BitBucket.

Step 1 : Create a new repository

If you don’t have an account with bitbucket.org, create a free account. Then from Repositories top-menu create a new repository. For the blog series, I created ‘MyProject‘ repository as shown below:

bit-bucket-1

once you have created the repository, you will get an admin interface that will look like this

bit-bucket-4

 

Step 2 : Create repository locally

Once you have created repository on bitbucket.org, you want push your changes to the server. Before you can do that, you need to right-click the ‘MyProject‘ folder and select ‘Git create repository here‘ as show below: (you will get these options if you have installed Tortoise Git)

bit-bucket-2

Step 3: Commit changes locally

The next step is to commit your changes locally. Few things to remember

  • Only commit what you think is required to be source controlled
  • Do not commit run time changes like /bin folder or /debug folder
  • Do not commit cache items as they will be local

For example, using tortoise git and right-clicking on the ‘MyProject‘ folder, if I do not want to add MyProject.TDS.Core/bin folder and all the files in that folder, I will just add that folder path to .gitignore file as shown below:

bit-bucket-6

As a minimum, I will also add a .gitattributes file and add the following settings as a minimum:

*.cs text=auto diff=csharp 
*.html text=auto
*.htm text=auto
*.css text=auto
*.scss text=auto
*.sass text=auto
*.less text=auto
*.js text=auto
*.sql text=auto

*.csproj text=auto merge=union 
*.sln text=auto eol=crlf merge=union

*.item -text

Step 4: Push changes to the Server

Once you have committed locally, you then need push changes to the server. But before you can push changes, you need to set the remote project URL from your client’s settings

For example, if this the project URL:

https://bitbucket.org/myusername/myproject.git

Then From right-click on ‘MyProject’ folder > Tortoise Git > Settings > Git > Remote add URL as shown below:

bit-bucket-7

Once you have set up the URL, and you try to push changes, the server will ask for credentials. Upon successful authentication your project files will be pushed to the server

bit-bucket-3

Once you have pushed your changes if you will navigate back to the admin interface of your project, you should see new folders and files created as shown below:

bit-bucket-5

Our project is now ready for continuous integration. In the next blog we will set up the servers and configure them for CI.

Stay tuned.

Thanks

Sitecore DevOp Series – Part 4 – Setup Sitecore Glass

This is the part 4 of the Sitecore DevOp series. Previously, we have installed a local instance of Sitecore, created it’s VS project solution and added TDS projects. In this blog post, we will configure Sitecore Glass Mapper for automated code generation using T4 templates. The blog series is aimed at newer audience and developers who are setting up CI for the first time.

Sitecore Glass

Sitecore Glass is an Object-Relation-Mappper (ORM) for Sitecore items. A common ORM that you may have worked previously would be Linq to SQL. Sitecore Glass helps in referencing Sitecore data item properties by using strongly typed C# objects. It is an open-source project and more information and tutorials are available from their official website.

Step 1 : Install Sitecore Glass for domain project

Sitecore Glass Mapper is available as NuGet package from the official Nuget feed server.
Assuming you have setup the ‘MyProject.Domain’ as per the previous post of the blog series, add a reference to the ‘Sitecore.Kernel.dll‘ within ‘MyProject.Domain‘ project:

my-project-glass-ref

Then add the official package via NuGet:

my-project-glass-ref-nuget

Remove the ‘App_Config‘ and ‘App_Start‘ folders from the ‘MyProject.Domain‘ project and add a custom class file as ‘Models.Generated.cs

my-project-glass-ref-remove-folders

Step 2 : Install NuGet package for main project

Install the same NuGet package for the ‘MyProject‘ , which is your main MVC project.

my-project-glass-ref-main

As of now, upon successful installation, you should see references to Glass.Mapper, Glass.Mapper.Sc and Glass.Mapper.Sc.Mvc. 

Step 3 : T4 Templates for Auto-Code Generation

As a starter, download the T4 templates as provided by the HedghogDevelopment github repository .

  1. Navigate to ‘TDS.Master’ project properties > code generation tab and check the box for ‘Enable Code Generation’. A folder will appear in the VS tree view as ‘Code Generation Templates’.
  2. Copy the downloaded T4 Templates files (with extensions .tt) that you downloaded from github within that folder and include them in the project via VS.
  3. Set the Target Project as ‘MyProject.Domain
  4. Set the code generated file as ‘Generated.Models.cs
  5. Set the base name as ‘Models
  6. Set the header transform file as glassv3header.tt
  7. Set the base project transform file as glassv3item.tt

 

my-project-t4-2

When you hit save, the Models.Generated.cs should give you auto-generated code for the ‘Sample Item‘ template as below:

my-project-t4-3

This is pretty amazing if you are doing it for the first time as now you can auto-generate your Sitecore data template properties and reference them in your main project as strongly typed objects. Every time you make a change to Sitecore templates, all you have to do is right-click the TDS.Master project, do a sync with Sitecore and it will update the code base. You can also ‘Re-Generate code for all items‘ as shown below:

my-project-t4-4
Adding reference to Glass mapper and configuring TDS project with code generation will make sure that any field name changes that you make in data templates are reflected back in the code. If there are any compilation issues due to referencing make sure you .NET version is correct.

We are all done in setting up the project locally, the next step is to add our project to a choice of our source control so it can be shared with rest of the team and with our build server. This will be explained in the next blog post.

Stay tuned.

Thanks

Related Blogs

  1. Part 1 – Continuous Integration – Why your Sitecore project deployments must be automated ?
  2. Part 2 – Setup and Configure Visual Studio Sitecore Project
  3. Part 3 – Setup and Configure TDS
  4. Part 4 – Setup Sitecore Glass
  5. Part 5 – Setup Source Control (Git)
  6. Part 6 – Setup QA Server, DB server and CI server
  7. Part 7 – Setup Continuous Integration using Team City
  8. Part 8 – Setup Slack Notifications with TeamCity and Bitbucket

Sitecore DevOp Series – Part 3 – Setup and Configure TDS

In previous blogs of the DevOp series, we have installed a local instance Sitecore and configured our VS for the sample Sitecore project. In this blog, we will add Team Development for Sitecore (TDS ) projects to our VS project. The blog series is aimed at newer audience and developers who are setting up CI for the first time.

Why do I need TDS ?

TDS is a great product for developing Sitecore projects. If you have not used it before, I would strongly recommend using it for your existing and new projects. The TDS seamlessly integrates with the Visual Studios and gives you a lot of options to manage Sitecore items. One of the main feature of TDS is that you can store Sitecore Items as serialized files on your local machine and push them to the source control repository. The development team can get the latest from source control, sync changes using TDS commands and update their local instance of Sitecore databases. This feature alone will save you and your team hundreds of hours development time.

The TDS can also automatically package up the data template changes for installations and deployments. It also gives you many more advance features for continuous integration which you can read on their official site.

Setup TDS Projects

Technically, you can have just one TDS project for your website and also configure it for continuous deployment. However, inspired from Pavel’s blog and personal experiences,  in this series we will be setting up the following 4 TDS projects

  1. MyProject.TDS.Core
  2. MyProject.TDS.Master
  3. MyProject.TDS.Master.Content
  4. MyProject.TDS.Master.System

TDS.Core project will be used to store any Sitecore’s Core database items like custom profile item or a new field type information.

TDS.Master project will be used to store Sitecore’s Master database items that are more specific to developers like templates, renderings, layouts, placeholder settings.

TDS.Master.Content project will be used to store Sitecore’s Master database items under the ‘Home’ node. If you have multiple sites, you can have multiple TDS.Master.Content projects, one for each site.

TDS.Master.System project will be used to store Sitecore’s Master database items under ‘System’ node. The ‘System’ node have items like ‘Workflow‘ or ‘Publishing Targets‘ or ‘Sitecore Powershell Scripts‘ that should be part of the source control, but we don’t necessarily need to deploy them every time.

All of the above TDS projects are optional and are meant for simplifying the deployment process as you will see in coming posts of the blog series.

Step 1 : Create TDS.Core project

Assuming that you have installed TDS for the correct version of your Visual Studios, right-click on the VS solution and click on ‘Add New Project’ and the select ‘TDS Project with Wizard’.

Give the project appropriate name like ‘MyProject.TDS.Core‘ and click on ‘Next’

my-project-tds-core1

On the next screen, set up the following parameters :

  • Sitecore Web Url
  • Sitecore Deploy Folder
  • Source Web Project
  • Sitecore Database
  • Check the install Sitecore connector

The example configuration is shown below:

 

my-project-tds-core2

Once you click Ok, a success message will pop-up and the new project should be added as below:

my-project-tds-core3

Step 2 : Create TDS.Master project

This step is similar to the previous one, except there is a small change when adding parameters on screen 2 of the wizard.

Right-click on the solution and click on ‘Add New Project’ and select ‘TDS Project with Wizard’. Give it the name as ‘MyProject.TDS.Master’ as shown below:

my-project-tds-master1

On the second screen, make sure to change the ‘Sitecore Database’ option to ‘master‘ and also un-tick the ‘Install Sitecore Connector’.

my-project-tds-master2

Click Ok and the project should be add to the VS solution:

my-project-tds-master3

Step 3 : Add TDS.Master.Content Project

Repeat the configurations for step 2, only changing name of the project

MyProject.TDS.Master.Content

my-project-tds-master-content1

Same parameters as that of step 2, un-tick the ‘Install Sitecore Connector’ check box:

my-project-tds-master-content2

New project should be added on clicking Ok

my-project-tds-master-content3

Step 4 : Create TDS.Master.System Project

Repeat the configurations for the step 2, only change the name of the project

MyProject.TDS.Master.System

my-project-tds-master-system1

Same parameters as that of step 2, un-tick the ‘Install Sitecore Connector’ check box:

my-project-tds-master-system2

New project should be added on clicking Ok.

my-project-tds-master-system3

Step 5 : Get Sitecore Items

So now we have our TDS projects installed and we would like to populate these propjects with Sitecore items. When you will right-click on the ‘MyProject.TDS.Master‘ project and try to click ‘Get Sitecore Item‘ command, it will be disabled as shown below:

my-project-tds-master-get-content1

This is intended behavior as during setup of the TDS.Master project we left the ‘Install Sitecore connector‘ option un-ticked. If you have left it ticked during the project wizard, it will create a different Access GUID for each project which will be incorrect for our 4 TDS project setup.

Copy Sitecore Access GUID

As we have only installed the connector for TDS.Core project, we need to get the ‘Access Guid’ and copy it across to the TDS.Master Project

For this, right-click on the TDS.Core project’s properties and navigate to the ‘Build’ tab. At the end of the panel, you will find ‘Sitecore Access GUID‘ property. Select and copy that value

my-project-tds-master-get-content2

Paste Sitecore Access GUID

Navigate to the build tab of ‘TDS.Master‘ project’s properties build tab and now tick the ‘Install Sitecore Connector‘ box, a random GUID will appear. Delete that GUID and paste the same GUID as for the TDS.Core project as shown below:

my-project-tds-master-get-content3

Verify connection for TDS.Master

Once you have copied over the same GUID, click on the ‘Test‘ button at the end of the panel to verify the connection details. They should all be green as shown below:

my-project-tds-master-get-content4

Get Sitecore Items

Once you have ran the test, give it like 60 seconds and try to ‘Get Sitecore Items’ again, now all options should be available and you should be be to get Sitecore items as shown below:

my-project-tds-master-get-content5

If you select to add the standard ‘Sample Item’ template and all its children by right-click options, it should appear as below:

my-project-tds-master-get-content6

Repeat the Copy/Paste GUID process for TDS.Master.Content and TDS.Master.System

my-project-tds-master-get-content7

Once you have repeated the process for all TDS.Master.* projects and populated them with Sitecore items, your VS solution should look like this :

my-project-tds-master-get-content9

That’s it for now, in the next post we will configure Sitecore Glass Mapper, TDS with T4 templates and auto-code generation for the Sitecore data templates.

Stay tuned.

Thanks

 

Related Blogs

  1. Part 1 – Continuous Integration – Why your Sitecore project deployments must be automated ?
  2. Part 2 – Setup and Configure Visual Studio Sitecore Project
  3. Part 3 – Setup and Configure TDS
  4. Part 4 – Setup Sitecore Glass
  5. Part 5 – Setup Source Control (Git)
  6. Part 6 – Setup QA Server, DB server and CI server
  7. Part 7 – Setup Continuous Integration using Team City
  8. Part 8 – Setup Slack Notifications with TeamCity and Bitbucket