Seeking Advice for using Web Deployment

Posted by Community Admin on 05-Aug-2018 15:03

Seeking Advice for using Web Deployment

All Replies

Posted by Community Admin on 12-Apr-2012 00:00

My current process is that I setup a project with IISExpress on my local machine and then use an FTP client to move files to our remote production server.

A typical installation is moving all the files over to the remote server.  Logging into that server and setting up IIS for the new site.  Then I launch Sql Server 2008 R2 and setup the db and make sure the dataConfig is corrected for the connect string.

I am fine with this, but am trying to determine if I can save myself some grief during my upgrade process.

I run the upgrade locally and then again will merge files to the remote server via FTP.  For larger projects this can get interesting on determining which files I truly need to move or not and it takes longer to manually go into each folder and que up individual files.  For instance, making sure not to copy configuration files so that the production database syncs up with the upgrade.

I have never used the web deployment tool with Visual Studio and it seems like it provides a lot of power, but I recall seeing posts somewhere that certain files with Sitefinity do not get copied when they should be.

I am looking for suggestions on how some of you set up your deployment projects and whether I would truly save any time by setting one up or if I should just continue using an FTP client since I have full access to the server anyhow.

Posted by Community Admin on 17-Apr-2012 00:00

Hey Stacey,

I'm using Web publish all the time and simply love it and couldn't go back to some other way really...

Defining configurations.
When starting a new SF project, you need to setup your 'configurations', basically defining the number of instances you have like 'debug', 'staging' and 'release'. Each of those configs will allow for a web.config transform file and for a publish setting.

With the web.config transforms, you easily define debug vs production settings like compilation mode, error mode and 404 page etc. That's standard .NET, so plenty of documentation to go around...

Publish settings.
On the publish settings you combine a 'configuration' with a location, either local or remote. 
Personally I use a local IIS instance for 'debug' in favor of IIS Express because its faster and IIS Express isn't IIS, so I don't want to run into compatibility issues.

Visual Studio solution.
My way of constructing a solution has been called 'weird' by some but it works for me, so feel free to totally do it differently. (see screenshot)

Next to the normal 'SitefinityWebApp' and 'SitefinityThemes' (Thunder project) I have created a 'SitefinityConfiguration' project. In there I basically store everything with regards to data and configuration. So under my 'SitefinityWebApp' project's App_Data folder, I just have an empty Configuration folder.

This means if I publish, no configuration files, or filesystem files will be overwritten.
Downside naturally is, I can't just press F5 to run the instance, but since my debug instance is a local iis, that's a matter of 20 seconds to publish.

By sticking all the configuration files and project data in a different project, in combination with source control, I'm able to attach it to whatever branch I'd like.

Publishing the solution.
Sometimes, some of the files in the 'SitefinityWebApp' aren't marked as content and won't get published. The license file seems to be default and with the latest release they forgot one other file, but usually nothing dramatic that'll take you ages.

When publishing my 'SitefinityWebApp' (local or remote) I'm ensured this way, that only my custom code and the project files itself get published and all the configuration files and filesystem files are left alone. If needed, I can publish the SitefinityConfiguration project aswell.

Database & publishing.
Usually when I'm on a hobby project, I locally use a SQL Express db that'll attach and leave the connection in dataconfig.config. When working on a client project with full sql server, I remove the connection string from dataconfig.config and put it back into web.config.

This way (in combination with the web.config transformations) publishing debug/staging/release will automatically assign the correct db.

Does it save time?
I believe so, maybe not directly with publishing itself but it definately ensures me that I can't accidently overwrite a .config file. And storing the configuration & data seperately from the project definately saves me time when switching back and forth between debug (with lorem ipsum data) and staging (with old client data).

If you still don't trust yourself to publish directly to the remote server, you can always publish the 'release' to a local folder and use FTP to upload the entire folder...


This thread is closed