We do our deployments as follows in our 8.1 environment using Team City, Octopus deploy and Unicorn (this is Simplified):
a rewrite rule tells the load balancer to take CD1 out of the pool
push the site NuGet packages to the CD and CM servers (we build this from Teamcity)
deploy sitecore, the updated site code and serialised unicorn items to the CM sever
Alex, there are many ways to approach CI deployments into your environments. Each client or organization is going to have different requirements as it related to versioning, restoring of backup, downtime, server access, etc...
Here is a great read that I think covers most of what you need.
TDS to Nuget
But we don't do just link answers here, so I ...
Yep. Using the NewItemsOnly evaluator.
Add this under your <configuration> element.
<evaluator type="Unicorn.Evaluators.NewItemOnlyEvaluator, Unicorn" singleInstance="true"/>
You can find an example of this in your Unicorn folder. Unicorn.Configs.NewItemsOnly.example
Be aware of a few caveats though. I've been using this one myself ...
Yes, you can do the sync with almost any kind of script. Basically you can call the /unicorn.aspx with parameters. Here you can find the whole documentation about this. This example is working with PowerShell.
Generate a very long random shared secret key, preferably using a password generator. There are no limits on character count, character types, ...
The Azure Module has been deprecated from Sitecore 8.2. We will be updating the module for 8.1 to support; new Azure SQL and SDK and most important change to Redis Cache Session State Provider (as the In-Role Cache service being shut down end of November).
The new Sitecore Cloud offering will be launched with Sitecore 8.2 update 1. Using ARM (Azure ...
We don't have a single package, but a package for each web project. Every web project has its publishing profile set to Web Deploy Package and the Package location is set to a unique zip filename in a common directory, e.g. ../Target/Feature-Navigation.zip.
The build server creates the packages with msbuild:
/t:build /p:PublishProfile=Release /p:...
I would highly recommend that you watch the following presentation by Mike Edwards:
Sitecore Nirvana - Continuous Deployment.
It's about two sets of databases being replicated. It all comes down to process at the end. You can definitely work through and come up with a process which works for you and your environment.
During deployments you would pause the ...
Sitecore Managed Cloud provides a hosting service for the infrastructure associated with Sitecore. The entire topology is owned and "managed" by Sitecore under their Azure Subscription. Generally, the definition of this topology is based on the agreement between the client and Sitecore. From what I have seen, this usually consists of 3 environments (DEV (XP ...
Some possible solutions to reduce build/deployment time:-
Reduce the number of projects in your solution by 'compacting' projects.
Reduce the number of projects in your solution by having a Tests-project-free sln file.
Create an sln file with the explicit ProjectDependencies removed. This would only be for local builds. It doesn't help you for your ...
We currently have the same issue and have been advised to set the following config (in Sitecore.config) to a higher value:
<setting name="Media.FileSystemWatcher.BufferSize" value="16384" />
We are currently trial & erroring this value right now, but others have reported a positive outcome.
You can have TDS generate an update package with all the Sitecore items and code, then use Sitecore.Ship or Sitecore PowerShell Extensions Remoting to install the update package.
Sitecore.Ship provides a web service to install update packages with - you typically use wget or something similar to stream the update file to the service. Anecdotally, wget hasn'...
That would be an XM environment.
You require: forms, core, web and master
This is a known issue and acknowledged by Sitecore. Whilst it is being further investigated, Sitecore recommend in their Knowledge Base article one of the following solutions:
Disable Dynamic Cache by creating an App Setting for the impacted App Service:
App Setting Name: WEBSITE_DYNAMIC_CACHE
App Setting Value: 0
Updating Sitecore Configuration and ...
With regards to the initial very large time, what you're most likely hitting is that Sitecore can max out the Azure SQL on startup to fill the prefetch cache - see Sitecore Knowledge Base Article 290593 The solution is to disable the prefetch cache by using the configuration file on the attached knowledge base article.
According to Sitecore:
The Sitecore ...
It is exactly possible to use the Unicorn for Continuous Delivery. I have some suggestions:
First of all, you need to put files (which are generated by Unicorn) under source control.
You need to use a config transformations for filling a correct path to the folder with the Unicorn's files.
The next very important part is that you should deny Unicorn to ...
If your only need is to keep the CD nodes only and you are okay with downtime on the CM, you can achieve 100% uptime of your CDs during deployments using a second publishing target.
CD1 => Connected to Publishing Target 1
CD2 => Connected to Publishing Target 2
By swapping which CDs are in the Load Balancer you can take your time and control when you ...
An options could be not to use courier, but to use TDS delta builds, considering the fact that you already use TDS, by going back to a certain date in time. This will also keep the packages small.
You could, by the way, use TDS package deployer to automatically install these packages as well.(https://github.com/HedgehogDevelopment/SitecorePackageDeployer)
Welcome to Sitecore!
There are two important concepts:
Publishing always refer to Sitecore Items. This will PUBLISH items from your master DB to your web DB (standard config).
Deployment is the deployment of your file system. On Visual Studio when you publish a project you are actually performing what is called "deployment" on ...
Is this the recommended way to include Support Packages and have them
available for an easy deploy?
The answer to your question will depend on your development environment and team setting. Below is the solution that works with our development process.
We include support packages in our git repo and Visual Studio solution. So for CI/CD we do not have any ...
In our project we try to create NuGet packages from them where possible and add them to our own internal feed.
When it replaces an existing Sitecore DLL (for example we've had a hotfixed Sitecore.Kernel.dll) we just use the package from our local feed in every project that requires it.
In case the hotfix adds a separate DLL with a config file to patch it ...
If your multisite Habitat solution is using a single IIS site, per the current license model. Then all the web projects (Feature/Foundation/Project) are batched into a single package. That is how we are currently doing it. We are publishing all the files to a single temp location, similar to a deployment. Then we deploy all the yml files and folder structure ...
If you take a look at the habitat demo - you will see that they use web.config.transform files. This is an example file from the Project/Common website project:
<?xml version="1.0" encoding="utf-8"?>
It is really not Sitecore specific but I'll answer this anyway.
Regarding your first question:
It's not the same since the web server running on your local machine routes the request to different sites depending on the url used in the request. In the case of Sitecore the web server is probably IIS. You can see and edit the configured sites in the IIS ...
If all your items on the Production environment are found on TDS, you can deployed them to your lower environments.
But if they are not, you can backup the Production databases (core, master and web) and restore them onto the lower environments. This is the approach I am using on all my Staging environments to keep them up to date with Production because on ...
The documentation for full wipe mode has been updated to reflect TP4 usage: https://jss.sitecore.net/docs/fundamentals/dev-workflows/code-first#import-full-wipe-mode
It looks like the documentation around wipe is out of date. With TP4, you need to set the SitecoreJSS.WipeAllowed config setting to true (as you already have):
Whilst your proposed setup is certainly possible with the help of a traffic manager, I would recommend using Deployment slots for blue green deployment.
With deployment slots, you deploy to a different slot, warm up your site and then swap the new code into production without downtime.
In this scenario, there is no need to sync databases.
If you want ...
You would deploy your main Sitecore application code to the Content Management and the Content Delivery app instances. Based on your list that would be:
If you do have any custom code for processing xDB data, you may also need to deploy to the processing instance, which looks like
in your list.
Update from ...
Application Initialization does a call to your website over http. If you have redirect rules that redirect http to https, the initialization receives a 302 and marks the request as done, it does not follow the 302 to load the site on https.
So in order to avoid this, you need to add an additional rules in your rewrite rules to skip the https redirect in ...
There are automatic cleanup tasks in place to deal with that.
Basically if you look under <scheduling> in a default Sitecore.config, you will find these.
<agent type="Sitecore.Tasks.UrlAgent" method="Run" interval="00:15:00">
To add to the answers above.
No Content in PRD
Make sure you make content in its own config/project. Then with transformation kill the config in QA/PRD.
No data provider in PRD
Make sure you turn off the the Unicorn data provider in QA/PRD. When the provider is on, Sitecore reads directly from the disk instead of the database. This makes it so ...