Working with Subversion, releasing every 1 or 2 weeks, how d - Sitefinity - On Premise – Configurations & Setup

All Replies

Posted by Community Admin on 17-Dec-2011 00:00

Is there any guidance how we can work as a team on a Sitefinity project using isolated, local instances? I'm looking specifically to learn what files we should add to version control, wat files or folders we should ignore.

Also, what are common configurations that are stored in the database, yet must be shared with the rest of the team? How would one go about sharing that?

Lastly, given the trends of content management systems in general to store data type and other configuration in the database, where does Sitefinity draw the line between code and content? And how does it impact our ability to deploy new code + configuration every week, while the customer continues to manage content, even when the site is already live.

I am specifically not looking for advice like "detach database and reattach" since that sort of workflow does not actually work after the first deployment, nor does it work in a team.

It can be for the latest version, since the project will start next year.

Thanks!

Posted by Community Admin on 21-Dec-2011 00:00

Hi Michiel Van Oosterhout,

You can have the Sitefinity Web Application in a source control system in the same way as with any standard ASP.NET application. You can put all the code in a source control system, if you need to do custom development for your Sitefinity application. In your development process, you also have the option to share the database or to employ local copies for each developer.
Best practices advice to exclude the configuration files from the project source control, so they will not need to be checked out. Anyway, if you want to put the configuration files in source control system, a better approach for each developer is to check out all configuration files before start working with the project.

All the best,
Svetoslav Petsov
the Telerik team

Do you want to have your say in the Sitefinity development roadmap? Do you want to know when a feature you requested is added or when a bug fixed? Explore the Telerik Public Issue Tracking system and vote to affect the priority of the items

Posted by Community Admin on 22-Dec-2011 00:00

Thank you for your answer! However, I was looking for some more detailed guidance.

What folders should be excluded from version control? I can imagine that Sitefinity has temporary storage?

And how do we separate content from code? What folders in the web application are changed when one developer is just testing with content? For instance, uploading images to test a content type. I don't think it's appropriate to store those in source control?

And why not share configuration? Wouldn't that result in code not working for the other developers if it depends on configuration? What types of code in Sitefinity depends on configuration?

And finally, should developers use a shared database or should each developer use their a local instance? What are the downsides for each option? If developers use a local instance, what problems can they expect when updated code depends on the database and how can that be solved?

Posted by Community Admin on 22-Dec-2011 00:00

Hi,

You can use separate branches and perform merge. For example branch from your core project and them when the development is done you can perform a merge operation of the files. Generally the database should be filled with data by editors once the development is done. You can have separate branch where you add data with some kind of items generator that uses the API and perform testing there.

Kind regards,
Ivan Dimitrov
the Telerik team

Posted by Community Admin on 16-Feb-2012 00:00

Ivan,

This post seemed like the most suitable for my questions and comments. We are just not starting to migrate all of our sites from 3.7 to 4.4 and have run into some issues with versioning the configuration files under App_Data/Sitefinity/Configuration.

One scenario we ran into was the Service Path at Administration -> Settings -> Advanced -> System -> Service Paths described in http://www.sitefinity.com/devnet/forums/preview-thread/sitefinity-4-x/general-discussions/failed-workflow-operation.aspx. The path is environment-specific and is set through the administration menu which gives no real indication where the file is being stored. This works for one environment and only one server if under a load-balanced environment. This poses a real problem when trying to move from DEV -> QA. -> UAT -> Production, because it's hard to know which files have been modified in the QA environment to get it to work properly without version history. Furthermore, some of our environments are load balanced and need the file on both servers which does not seem to work when using the administrative menu (it sets one server but not the other).

What I think we are going to do is prevent write access to most of the config files everywhere besides localhost or possibly DEV and then keep these config files in source control. That way they can be pushed along with the code each time and ensure consistency across all environments.

I'm not 100% sure this is the best solution since it prevents administrators from making changes in the back-end in the production environment, which is kind of the point of the whole set up.

So I thought I would throw out my proposal to the SF community to see if anyone has a better recommendation or has already solved this problem in some other way. Any recommendation is greatly appreciated.

Thank you,

Scott McNeany
Software Developer
International Medical Group, Inc.

Posted by Community Admin on 07-Mar-2012 00:00

Any thoughts on this?

Posted by Community Admin on 07-Mar-2012 00:00

Any thoughts on this?

Sorry for the duplicate post. Not sure what happened there.

This thread is closed