Hi Emma,

That will probably work well for smaller setups but I think you should also have a look at Octopus Deploy (together with a build server of course). I see more and more people using it and it works well for EPiServer projects. The only problem I'm having with it regards the deployment of EPiServer Add-ons which requires some special tricks, but it's doable.

/Emil

Hi Emil,

Thanks once again for your valuable post. 

When you say I need a build server? What is that, CruiseControl server or do you recommend any server for that too? Sorry if you found it silly, i just want to know how to start this.

Note:- Just editing the same post as I have learnt a few things more about octopus deploy.

Octopus takes package files and do the deployment. So, my question is I still need to use the MSBuild/Transform to create packages or Visual Studio TFS will do the build package right? And that package will be used by Octupus. Please correct me if I am wrong. So that, means I do need to have a build server or Cruise Control along with Octopus.

Also, can Octupus work without any build server?

Kind regards,

Emma

Hi Emma,

There are no silly questions, only silly answers :-)

The standard setup if you have a reasonably established development process is to have a build server (such as Cruise Control or Teamcity, the latter being more widely used I guess) so that every time you commit some code into your source code repository (be it Git, Team Foundation Server, Subversion, or whatever) it takes the code and builds the application. It then runs any unit tests and integration tests you might have in your code to see that everything works. This is called Continuous Integration.

The next evolutionary step is to use the build server for deployment as well. If all tests pass without failure then the required deployment package(s) are built so that the application can deployed from a common environment, removing the risk of different behaviours when deployed from different developers' machines and it also takes the manual hassle out of the process (so you're not tempted to copy a single file rather than the entire application and other bad habits). The type of package to build depends on your needs, one alternative that I've used many times is to build Web Deployment Packages that are easily scriptable for deployment and they are also easy to configure using Visual Studio.

To remove the last manual step of copying deployment packages and executing them, it's common to initiate this process automatically from the build server after successful builds. This is called Continuous Deployment and is the preferred method since it is more stable as it requires no manual steps. It also encourages small incremental deployments that takes place every time you change something in the code. Deploying a new version is then much less scary than if you do it seldom and manually. This is where Octopus comes in as it takes deployment packages that the build server prepares (in the case of Octopus it's a form of Nuget package) and installs them in the target environments (configuration in Octopus controls the environments to deploy to, which web sites to create, etc).

Note that you normally only do continous deployment into test and staging environments. You can of course do it for production as well, but normally some kind of acceptance is required and when you have that you can initiate the deployment into production manually, but you'll still do it from the build server (or the deployment tool).

As you can see there are quite a bit of stuff to set up and this usually takes some time in the beginning of a project, so you should be prepared for that. A week or two is not uncommon (even if you've done it before), although that normally includes quite a bit of fiddling with servers and infrastructure that you'd need to do anyway. But if you have a small project it might not be worth it and in that case I think your best alternative is to create Web Deployment Packages and config transforms from within Visual Studio.

As for your question, I haven't heard of anyone using a tool such as Octopus without having a build server but I suppose it might be possible. But I would strongly suggest starting to use a build server regardless of deployment needs as that adds incredible value to the development process. Spend time on that first and do deployment manually until you're ready for taking the step into Continous Deployment Wonderland :-)

Hope this helps.

Cheers

Emil

Hi Emil,

Thank you very much for explaining me in detail every bits of it and for your time.
I seem to getting it now. If I have a small project, as you said, you could use web deployment packages and config transforms from within Visual Studio.

I am slightly learning how this transform works and deployment package.

1. What I understand is, transform gives you different level of configuration files, basically the differences that you have amongst different environment like Development, Stage, Production.
Please correct me i am wrong.

2. There is also a script written in post build event? Do we really need that?

3. And then I need to use deployment package to deploy it? Can you see any limitations in using it?

Many thanks,

Emma,

Hi Emma,

• Yes, config transforms allow you to change parts of the original config file and keep the rest as it is. This is useful since most of it will be the same between all environments.
• Probably not. It's sometimes useful to be able to copy files to a given location, and things like that, in the post build event script, but you're not likely to need that right now.
• Not really. They have limitations, just like any other technology, and since you seem to be starting up I think they're a good bet. Also, if you start using config transforms and later decide to switch to e.g. Octopus you can reuse the same transforms in Octopus.

Good luck!

Emil

Hi Emil,

Thanks a million, I will try to set this up accordingly and will come back if I face any problem.

Just quick questions i am confused with.
1. When I use config transforms, and build the project, the post build event is only trying to run MSBuild command.  To generate build I can use MSBuild directly right instead of using Postscript?

2. When I use MSBuild and try to generate a build, it says few missing dll references. Although all the references are already in the Project solution "references" section and the project comiples and run susccessfully in Visual studio envirnoment. Did i miss anything or how do i fix this.?

Kind regards,
Emma

Hi Emma,

1 No you don't need a "post build event script" for transforms. Transforms are performed when publishing the project, not when building it. "Postscript" is used for printing so I assume you're referring to Powershell? You don't need Powershell to generate a deployment package but the package itself contains of a set of zipped files and a Powershell script to perform the deployment.

2 What do you mean "when I use MSBuild"? Are you building your code from the command line instead of from Visual Studio? I don't know your reasons for that but the problem is probably that you haven't set up the environment in your command line console correctly for building .Net solutions. Search for "Visual Studio Command Prompt" or something similar to that in your start screen and see it ot works from inside there. Or better yet, get a build server so you don't have to bother with stuff like this. :-)

/Emil

Emma

Do not look at the old version 7 (or older) examples of Alloy created by the deployment center. They used pre and post build events that was very hard to understand.

It is better that you create a project with the addon to Visual studio and create a new site with that. It will not use msbuild and postbuild event anymore.

To automate your process you should use a build server, or deploy to Azure directly from source control. As Emil has described the CI and CD world is big with a lot of different solutions and can be done in a whole lot of different ways.

CCNet (Cruise Control) works fine and are free but Team City is more easy to use and if you do not have many projects it is also free. You can depoly from for example Team City directly to the production enviroment and it works very well but it you want a "real" CD process you should use something like Octupus deploy to do the deployment and Team City to do the build, meaning that each program are responsible for the thing it does best.

To make the transformation work, you create a transformation in visual studio (right click on web.config and choose add Config transformation) and then add some transformations (read more here: http://msdn.microsoft.com/en-us/library/vstudio/dd465318%28v=vs.100%29.aspx). This will kick in when you for example right click on the web project and choose publish.

So the main question is: How automatic do you want it?

Thanks Emil and Henrik once again for your valuable comments.
Now the question: how automatic do I want it?

I was looking for a proper way of doing it, and so far as you suggested, it is really not a small process to implement all of the team city, build server etc at once.

So, i will explain the way we are doing it, which we want to change and do it in more appropriate way:-

We have Configuration folder where we have a "Common" folder, a "Debug" folder and a "Release" folder.

Configuration Folder
a. Common folder:- As name shows, common is for common files.

b. Debug Folder:-
holds connection string, episerver framework, episerver config with different developer machine as name for example.
When we setup the project on one machine, we need to generate debug file according to that machine to make it run.

for ComputerA
  connectionStrings.ComputerA.config
  episerver.ComputerA.config

for ComputerB it is connectionStrings.ComputerB.config

  connectionStrings.ComputerB.config
  episerver.ComputerB.config

c. Release folder

Folders for different Website

Post build Event

Now, the post build event has scripts using XmlConfigMergeConsole.exe which merges the relevant files.
This script is really cumbersome 

Q) Question is if this is a good approach to follow?

Q) What can I do in some quick steps to improve the above process.

Thank you once again for taking time to read my posts.

Cheers,
Emma

Emma, that sounds like a very complicated way to set up the development enviroment, and sounds more how you have to do it with version 6 of EPiServer.

There are no need to have episerver.config and episerverframework.config as their own files any more since all configurations nearly have moved to the computer. The way to do it now is to have the information from these two files inside web.config and with that be able to use config transformation on it if it is needed (propably not).

Why do you have one unique connectionstring.config for every developer?

For the database there are two ways to go:

1: Share a database between all developers. This will give you a easy setup but will be troublesum if there are a lot of developers doing different things, since the database might be changed on build if you have a new pagetype or something like this.

2: Every developer use their own database on their computer. This is the prefered way since it isolates the developer so his or her commits does not effect the others until it is push'ed (to talk GIT-language ;-) ). This does however demands a little more setup since a database must be created for every developer and it might also be needed to be filled with information. The create database part I am note shore on how to do the best way but for the information a "setup-file" can be included in the project and the first compilation will fill the database with needed information. To see how that is done, look at a Alloy project created with the latest version of the Visual Studio plugin. If I am not wrong this is just a export file that is placed in the AppData folder. With this you do not need to have a different connectionstrings.config for every developer, since everyone is using localhost and trusted login.

With both the above you move the content from connectionstrings.config in to web.config so you can do config transformation on it. (also here, look at the latest Alloy MVC example to see how to do).

Hi Henrik,

Many thanks once again for taking time again to read my post. I am trying to get a hold on it now.

When you wrote that move contents from episerver.config and episerver.framework to one web.config, I have seen it the way I installed the new 7.5 templates. I installed it from nuget package through extension manager in VS, I 've found that it does not have any episerver.config and episerverframework.config files which confirms what you mentioned about one web.config. right?

Now, after this, I just need to apply transform to the web.config as you mentioned, correct me if I am wrong.

"To make the transformation work, you create a transformation in visual studio (right click on web.config and choose add Config transformation) and then add some transformations (read more here: http://msdn.microsoft.com/en-us/library/vstudio/dd465318%28v=vs.100%29.aspx). This will kick in when you for example right click on the web project and choose publish"

So after the transformation, do I need to run any post build event to create a package/build for different environment or just use msbuild to do it to automate the process,  I am confused here a little bit. Sorry for being silly once again. Meanwhile, I am also reading in detail how transformation works in the article you mentioned. 

Kind Regards,
Emma

If you are meaning my comment Chris I am very glad that I works for you! Thanks for the nice words!

@Henrik: Chris comment above was spam. Sorry. :)

@Per. Ok, well, it was nice words anyway :-)