+1-888-365-2779
Try Now
More in this section

Forums / Deployment / Working with Subversion, releasing every 1 or 2 weeks, how does that work with Sitefinity?

Working with Subversion, releasing every 1 or 2 weeks, how does that work with Sitefinity?

7 posts, 0 answered
  1. Michiel van Oosterhout
    Michiel van Oosterhout avatar
    14 posts
    Registered:
    26 Apr 2010
    17 Dec 2011
    Link to this post
    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!
  2. Svetoslav Petsov
    Svetoslav Petsov avatar
    456 posts
    Registered:
    24 Sep 2012
    21 Dec 2011
    Link to this post
    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
  3. Michiel van Oosterhout
    Michiel van Oosterhout avatar
    14 posts
    Registered:
    26 Apr 2010
    22 Dec 2011
    Link to this post
    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?

  4. Ivan Dimitrov
    Ivan Dimitrov avatar
    16072 posts
    Registered:
    25 Nov 2016
    22 Dec 2011
    Link to this post
    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
    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
  5. Scott
    Scott avatar
    11 posts
    Registered:
    06 Aug 2012
    16 Feb 2012
    Link to this post
    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.
  6. Scott McNeany
    Scott McNeany avatar
    44 posts
    Registered:
    09 Mar 2010
    07 Mar 2012
    Link to this post
    Any thoughts on this?
  7. Scott McNeany
    Scott McNeany avatar
    44 posts
    Registered:
    09 Mar 2010
    07 Mar 2012
    Link to this post
    Any thoughts on this?

    Sorry for the duplicate post. Not sure what happened there.
7 posts, 0 answered