Deployment Improvements

Hi all,

For the upcoming Sitefinity 9.0 release we plan improvements which will ease the deployment process and will allow the effortless inclusion of Sitefinity projects in a Continuous Delivery setup.

Please, review and let us know what you think! Is there anything important we are missing?

Sitefinity 9.0 Deployment Improvements:

Enabled Deployment of Sitefinity Data Structures
(Dynamic Modules, Custom Fields, Custom Taxonomies, etc.)

Certain user actions in Sitefinity result in data structure updates. These include creating dynamic modules and content types, adding/removing custom fields, etc. Currently, you need to repeat those actions on each environment where you want to apply such updates.

To illustrate with Dynamic Modules:
1) First, you need to create it on the local machine.
2) Then, you need to manually recreate it on each next environment (Stating, Live, etc)

In Sitefinity 9.0 it will be possible to export Sitefinity Data Structures (Dynamic Modules, Custom fields, Custom Taxonomies) to a files in App_Data, and then deploy these files to other environments. The files will contain the module structure and custom fields. On the receiving environment the Sitefinity database will be updated to contain the dynamic structures specified in the file.

This will enable the deployments of Dynamic modules, custom fields. and custom taxomies.

Simplified Deployment of Upgraded Configurations

Currently, you need to upgrade Sitefinity configs on the local machine and then on each environment separately. This adds unnecessary steps to the deployment process, such as:
1) Excluding upgraded configs from the check-ins to source control, and
2) Merging upgraded configs from live environment to source control.

In Sitefinity 9.0 it will be possible to upgrade configs on the local machine and deploy the updated files to other environments. This will eliminate the need for the steps above and will simplify the upgrade process.

Simplified Dynamic Modules Config

Currently, creating or updating Dynamic Modules stores all default configurations of the module in a DynamicModulesConfig file. With the addition of new Dynamic modules, the DynamicModulesConfig file becomes very big and hard to maintain and merge.

In Sitefinity 9.0 we’ll simplify the storage of Dynamic Modules configurations. The default module configurations will no longer be stored in the DynamicModulesConfig file. Only updates made by developers will be exported as separate config files split per type and per view.

To illustrate, if the backend list view of Album content type from Knowledge base dynamic module is updated, the following config files will be generated: KnwldgBse.AlbumBackendList.config.

This will reduce greatly the size of DynamicModulesConfig. Also, it will ease the tracking of updates made to the default Dynamic Modules. 

We are planning to release a Beta in a month,and you can test the improvements above.
In the meanwhile, any feedback is appreciated!

Thanks for announcing this. Good plans! The first two features will be a massive time saver and prevent errors.

A nice to have but not essential would be if "Enabled Deployment of Sitefinity Data Structures" would also work for classifications.

The relatively new "System is initializing" message after an upgrade/restart never recovers when requesting a back end page. Might be something to look into too.

I assume all deployment related features will be available for all licenses? (Standard to Enterprise)

Hi Arno,

I confirm that the new feature "Enabled Deployment of Sitefinity Data Structures" will include custom taxonomies as well. I have updated the original post to reflect this fact.

I confirm that those features will be available for all licenses.

As to the "System is initializing" message not recovering correctly - we will check this behavior and let you know if more info is needed. 

Best,

Kalina

Hi Kali,

This looks like a very good feature.

I would also prefer to be able to import also data. For example - we can have XML for the dynamic modules, custom fields, and taxonomies, but also having the option to add the content - this way we can test with the content. 

By the content above I mean:
- Sites (including providers etc.)
- Page templates

- Pages
- Content items (Images, Documents, News, Dynamic content, etc.)

This way when I launch the site it could be used for

a) automated UX testing - including the content that the UX test expect.

b) feature deployment - you deploy the changes, with the "predefined/populated content". We usually have some content.

The ability to deploy content will simplify also the content migration between environments, e.g. we have no connectivity to the production environment (customer's security policy), but we can copy a package with "content" and then fire the import.

I remember the above feature from SDL Tridion about 6-7 years ago it was available, it looked quite similar now to the SiteSync - step 1 - select what you want to export, next get a zip package, step 2 - copy the package to place with access to the target server and import (you can also select what you want to import). The packages included (Publications - Sitefinity sites, Schema - Sitefinity content types + custom fields, Taxonomies, Content presentations - Sitefinity widget & page templates, Content - Content of the content types, Site Structure - Sitefinity Pages). You could also select the language of the content that you wanted to Export/Import. I think I got quite off topic.

Regards,
Kiril

@kali

So do the new DynamicModule config changes finally fix this?

feedback.telerik.com/.../141517-module-builder-custom-filters-created-for-the-backend-dynamic-content-items-disa

Also how is the Dynamic "structure" export different from right now where we export\import the structures in the module builder? ...are we finally talking DATA import?

I like all the initiatives proposed.

One thing I would like to see added is the nugget packages you provide that they also update any SitefinityWebApp files and configs. It would be good if we don't need to use the Project Manager at all. (I am currently under the impression that it doesn't do everything so please correct me if I am wrong)

@Kiril and Steve,

You are right in assuming that as a next step we will also enable the export import of Sitefinity Data.
This will allow you to export a whole site or a subset, and use it for deployment on another environment or to import on another Sitefinity project.
Phase I will be delivered in Sitefinity 9.1, and I will post an announcement with more details in this forum shortly.

@Steve,

1. I confirm that this issue will be resolved with the new implementation.
2. Data structures export import differ from the current Dynamic module export in that they can be included in a standard deployment package.

Updates in the database structure on the receiving environment are applied on application start and there is no need to import the module manually via the interface.
Also, Data Structures will contain updates in addition to dynamic modules, such as: custom fields in static modules and custom taxonomies.

@Darrin,

We are planning to support the distribution of Sitefinity modules and sites via NuGet packages.
As a first step, we will prepare instructions on how to distribute Sitefinity dynamic modules and custom widgets in a NuGet package.
At this moment, we are researching on what is the best way to include configuration updates in NuGet package.

These are the options we consider:
-- Export all config updates to an xml file. Transfer them to the other instance.
Apply the config updates on application start. Similar to what we have in Dynamic modules export import today.
This approach will work when configs are stored in the database on the target instance. 
-- Export all config updates to config transformation files. Transfer them to the other instance via NuGet. Apply the config updates on NuGet package install. Similar to what is described here.
This approach will not work if configs are stored in the database on the target instance. Also, it has dependency on external tool, such as NuGet.

@ All: We would love to hear your feedback on the two approaches for transferring config updates above. Which one do you prefer?

Best,
- Kalina

Hi Kalina,

My suggestion is to avoid dependencies on external tools at all cost. That's what I try to do for our website in general too, as in my experience more dependencies = more trouble sooner or later.

For the same reason I prefer to keep custom code to a minimum. The more standard features are available in Sitefinity, the better it is.

I would like to see the DynamicModulesConfig no longer be internal. We have had projects that need to modify the config programmatically but have been unable to do so without resorting to parsing the raw file as XML.

Please make this class accessible to custom code.

Related to this I'd like to see support for Dev vs Production configs. 
Something like SlowCheetah so that an Azure deployment can have its unique config requirements turn on (like ElasticSearch) but it also works on the local developers machine where these features don'e exist. 

Hi Kali,

Any progress of the export of the Sitefinity Data structures as Nuget Packages?

Today (SF9.1) we can export a given module, its content and then import it to another Sitefinity. We can also  use "Export for deployment' to export All dynamic module structure info a given directory. But how to we use this export? How can be import it back? Can this be automated? Are there any powershell modules foreseen to push them to a running sitefinity?

Thanks for your help.

Alex

Hi Alex,

The way to import the structures that have been previously exported for deployment is to copy/paste the ~\AppData\Sitefinity\Export folder to the new instance. On next site restart, Sitefinity will pick up the changes and import automatically.

Please let me know if you have further questions.

Mariush