I just started working with EPiServer (Sitecore before) and looking for a way how to synchronize content between environments automatically (developer-developer and developer-QA env).
We have our QA environment on an azure virtual machine and need to synchronize content during CI/CD.
EPiServer DXC Service doesn't meet the requirements because we are not working on a web app service.
Any ideas? Is there any already existing way to achieve it?
Automatic synchronization between environments has [more-or-less] gone away within the Episerver platform. The old way of doing this was using mirroring, but that's not available in the DXP, and is eventually being removed from the platform in favor of other strategies:
For moving bulk data (content items, content types, categories, visitor groups, etc.) between different environments, without touching code or the database, use the "Import Data" and "Export Data" tools within Admin mode. More information here: http://webhelp.episerver.com/latest/en/cms-admin/exporting-importing-data.htm
For bigger bulk migrations of data between environments, typically a database backup and restore is done between environments. Obviously, this is a bit more risky when involving a production environment.
If the content (or a content type change) is required as part of a deployment, you can build a content migration step. More information here: https://www.gulla.net/en/blog/renaming-an-episerver-page-property-using-a-migration-step/ and https://world.episerver.com/documentation/developer-guides/CMS/Content/Refactoring-content-type-classes/
If you are simply wanting to move authored content from a staging environment to production, it's suggested to create all content in production and use Episerver's Projects feature. More information here: https://webhelp.episerver.com/latest/en/cms-edit/projects.htm
If you are using Azure DevOps for CI/CD you might want to look into Epinova DXP Extension to Azure DevOps - that uses the Episerver deployment API but makes this easier to set up your pipelines. See https://www.epinova.no/en/folg-med/blog/2020/episerver-dxp-content-harmonization-with-epinova-dxp-deployment/ for more info.
Take a look at the Deployment API. There might be something in there for you. https://world.episerver.com/documentation/developer-guides/digital-experience-platform/deploying/episerver-digital-experience-cloud-deployment-api/
Related
As far as I know, regarding web-roles, it is possible to have multiple ServiceConfiguration.cscfg files, one for each publish profile (for example, Cloud1, Cloud2, Cloud3, Local and so on).
Though, is it possible to have different diagnostics.wadcfg (wadcfgx) files?
How to instruct Visual Studio to use a specific diagnostics file when deploying to Azure? Is there a specific entry in the publish profile XML file?
Out of the box, it is not possible because there can be only one diagnostics.wadcfg (wadcfgx) file associated with a role in a cloud project a cloud project.
We are using SDK 2.4 in our project and the way we have worked around this problem is by creating separate cloud projects for each environment - Dev, Staging, and Production. Since these are separate cloud projects, we can have different diagnostics configurations.
If you're using SDK 2.5, one thing that works in your favor is the diagnostics is now an extension (instead of plugin). What that allows you to do is change/enable/disable diagnostics on the fly. Though I have not tried it but one thing you could possibly do is enable diagnostics as a part of your deployment process. By default there won't be any diagnostics.wadcfgx file in your project. When you deploy your code via PowerShell, after successful deployment, you can enable this extension. Please see Step 4 here: http://azure.microsoft.com/en-in/documentation/articles/cloud-services-dotnet-diagnostics/#worker-role. (Since I have not tried it myself, I would be very much interested in knowing the outcome. Please do share if this approach worked for you).
I am searching for blog of MSFT article which speaks about publishing/deploying SSRS reports to DEV- QA - Acceptance - PROD SharePoint 2013 in Integrated mode.
Can someone advice if creating a feature/solution and packaging them for deployment is easy way or if there is another way to deploy this reports in the development lifecycle? with every environment(DEV, QA, UAT, PRod) the link within datasource changes which also needs to be dynamic, is it possible?
Within the project properties in SQL Server Data Tools/BIDS, you can define your various environments and enter the appropriate urls for data sources, reports, and server that environment in the deployment properties. Once these are set up, you can choose the correct configuration for the appropriate environment. Then when you click deploy, it will go to the correct location for that environment. Do not be fooled by the Configuration drop-down box on the properties page. You actually have to click the button to switch between configurations.
So change it here:
Not here:
For the data sources, make sure you are using shared data sources and that you set Overwrite data source in your project properties to false. Then update the data source to be appropriate to the environment and deploy it once in each environment. You won't have to do this in the future since it will now be out there. This means your SSRS data source must have the same name in each environment. If you change it in the future, you need to update it and redeploy in each SharePoint environment. Here's a blog post describing this approach.
Live to Development Migration
We are currently migrating some sharepoint sites from external live environments to development environments hosted on vm's. The sites are a mixture of websites and intranets. We have not had access to the live environments so can not specify structure of the sites.
The sites do have some customisations applied. Some are customisations are packaged via wsp packages for which we have the source code (somewhere previous developers have left it need to find it)
The sites setup we have no knowledge so the objective is to restore live back to a development vm so we can bug fix and make enhancements moving forward.
What steps should be go through for this.
We have outlined the following steps:
Take a copy of the content databases/s
Take a copy of the wsp packages straight from the live environment (using powershell)
Create site collections from live on dev
Restore the content databases from live on to these.
Deploy the wsps from live on to dev.
Activate the features from live on our development vm's.
What other steps are missing as I am sure they are.
What I would add here are:
Make sure your notifications don't go to the users of live environment
Make sure your BDC and custom connectivity components don't modify or otherwise load production external data sources
Document and verify (using PowerShell) that all assets are deployed accurately, because sometimes you'll face issues such as event receiver registration, etc.
Make sure your InfoPath forms are reconfigured to use the updated data sources
Make sure your Alternate Access Mappings and Incoming/Outgoing Email settings are adequate
Why does Microsoft suggest using WSPs for production deployment in SharePoint? What are the other methods for production deployment?
WSPs are suggested as they are deployable 'bundles' of functionality, whether that is an Event Handler, Application page or Web Part. By using WSPs you can create and test them in Dev and then roll them out to production once they have been tested. A WSP can be easily managed from the Solution store in Central Administration
It is possible to deploy features by putting the necessary files into the 12 Hive (SharePoint ambiguously named folder), but this requires manual changes to the system. If you have several Web Front Ends (WFEs) in a web farm, then you would need to manually maintain each of them. When using WSPs for deployment, the updates can be deployed to all Servers from one location.
WSP files are designed for deploying functionality to SharePoint in a consistent manner. Although technically they don't do anything you can't do by just copying files to the server, relying on manual deployment is a great way to put the system into an inconsistent state. It may work at first, and even be quicker/easier in some cases, but sooner or later you will permanently break your production environment.
The wsp was specifically designed for the purpose of packaging and deploying SharePoint 2007 solutions. That's why Microsft suggests using it!
While there are a few limitations to it, it's by far the best way to deploy solutions into a prod environment.
You should use WSPs to deploy in SharePoint.
I have used this WSP builder and it's makes your life a little easier.
http://www.codeplex.com/wspbuilder
I feel like I need a better defined framework for updating my SharePoint (MOSS 2007) application with custom code changes. I am creating wsp solution files with features and new types and such, but once those get tested and deployed, I feel like it's a bit of a leap of faith, and that makes me nervous and occasionally reluctant to deploy changes. After deployment, it's difficult to correlate the current state of the SharePoint application with the specific code that is deployed on that SharePoint server. What features are actually installed and on which sites? Which features are activated or deactivated? Which version of this custom field or content type is really there? Things like this. If an error crops up, I have to rely on my assumptions about what code is there and actually running, or I have to spend time digging through deployed assemblies and the 12 hive -- not impossible, but pretty unpleasant.
What steps should I take to improve my ability to unambiguously determine the state of the application and find the code that truly represents that state? Are there third-party tools that can help with this?
I feel your pain... Application Developyment Lifecycle with SharePoint 2007 leaves me with a bitter taste in my mouth.
To answer your question. We built our own deployment utility that does a few things for us.
Checks state of key Timer Jobs (too many times we would do a deployment to find one WFE that did not get deployment)
Checks state of key Services on all our web front ends (again we want to know health of farm before we start kicking off timer jobs).
Shows file version and date of selected assemblies from GAC (does this across all Web Front Ends). We have seen problems before where assemblies did not get installed correctly across the farms.
Updates web.config settings based on an custom XML scheme we provide. We ran into some problems with web.config updates so we have thought about creating a utility to validate the web.config (specifically make sure there are no duplicate entries for specific keys).
Push content type updates (first time content types are deployed via feature it works great, but as soon as you need to update that content type it gets tough).
Checks status of WSP package after deployment or upgrade.
This utility uses the SharePoint API to do most of this work. Some of it is done by checking WMI Events.
Unfortunately the SharePoint development experience is lacking in this regard. As long as you are "namespacing" all features deployed using solution packages, you can use solution management from central admin to keep track of versions, and what gets deployed to which site collection.
Features are scoped from all levels from the farm to an individual web; so maintenence from that level is a little tough. I just try to organize all deployed code from the (top down) solution level.
It gets even more complicated when deploying custom timer jobs, event handlers, etc; I really hope that version next will address a lot of these common developer concerns.
Isn't the only way that you have a planned/controlled deployment process and a version management system like TFS
In the current project I am involved in we have:
Continuous builds
Daily Builds on a development server
When we release something to test we merge the code to the Main bransch in the version management system (TFS)
When tested and ready for production then we merge the main bransch to the release bransch
Using this structured way we always knows what is deployed in what environment and can also track all changes based on environment or changes in requirements(are also tracked in TFS)