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

Forums / Developing with Sitefinity / Setting up a development environment

Setting up a development environment

5 posts, 0 answered
  1. Grey
    Grey avatar
    9 posts
    Registered:
    09 Sep 2013
    12 Sep 2013
    Link to this post
    My question comes from a problem I encountered after reading this thread (good article btw) - where the author attached a project of sample code (for review) at the bottom of the article - found here:

    http://www.sitefinity.com/blogs/lubomir-velkovs-blog/2012/02/09/inter-field_communication_dynamic_states_dropdown_depending_on_a_country_dropdown

    My question is so basic (as to be embarrassing) but being a noob to all things Sitefinity...was wondering - does anyone have any (can you point me to?) - clear and basic - instructions/advice as to how to integrate an attached project into a 'development environment'...say a development environment/configuration purposely set up to develop for Sf Web Sites?

    For a team of several developers (to build custom widgets, templates etc) for Sitefinity projects - is there (anywhere?) a basic set of instructions on how to create a development environment? - One (I imagine) meant to be used for (said) attached project to be integrated and run from?

    Any help - would be greatly appreciated,

    GG - MN
  2. Arno
    Arno avatar
    249 posts
    Registered:
    08 Sep 2010
    12 Sep 2013 in reply to Grey
    Link to this post
    Hi Grey,

    You need Microsoft Visual Studio. The Express version is free.
  3. Grey
    Grey avatar
    9 posts
    Registered:
    09 Sep 2013
    12 Sep 2013
    Link to this post
    Thanks Arno - the question is actually more basic then I was able to initially convey. So we have VS 2012 and are using TFS for version control...we're employing Thunder...know of it...and have seen it used in some training videos.

    So - how have people set up their development environments for something like custom widget development? Do you have a mock site that you mess around with and then port your finished (in this case) custom widgets over to your client sites?

    The project file created in the referenced in my initial post:

    http://www.sitefinity.com/blogs/lubomir-velkovs-blog/2012/02/09/inter-field_communication_dynamic_states_dropdown_depending_on_a_country_dropdown

    ...it's obvious the author created the project (attached at the bottom) for illustration purposes...presuming that people who wanted to try the code out would important the project into their development environments...customize/tweak to their hearts content and then use said code...is what I imagined.

    So when reading it...I became curious as to how people had set up their dev environments? If there were any special unique considerations - in dealing with a CMS and developing custom features for sites that use Sitefinity - that (architecturally?) make certain considerations/steps from dev-staging-deployment more important? So 'strategy' might be a good word...considering that time is only going to bring more clients...and you'll also have to upgrade as new feature sets become available etc.

    With a CMS standing in the middle of - what might be called the business of web development...does that added 'layer' add a degree of complexity when envisioning a strategy for creating a development environment?

    Thanks,

    GG - MN
  4. Stuart
    Stuart avatar
    33 posts
    Registered:
    01 Nov 2012
    13 Sep 2013
    Link to this post
    Myself and the other developer both simply replicated a production setup on our development machines:

    - Source code in the C:\inetpub\wwwroot directory
    - IIS with an appool for each site, and a website that points to that directory
    - MS SQL Server with a database for each site (running locally), pointed to by the dataconfig.config file
    - Edit files in visual studio, build in visual studio, and then load the page in the browser.

    We use git for version control, and for all code changes to staging and production, the code is pulled and built. Configuration files are excluded from version control so that we don't overwrite settings that were changes by users in production (and so that the database references don't get overwritten with dev settings). All custom modules and database changes are replicated by hand for production sites.

    It's a bit of a pain, but it works pretty well. 

    Stuart
  5. Grey
    Grey avatar
    9 posts
    Registered:
    09 Sep 2013
    17 Sep 2013 in reply to Stuart
    Link to this post
    Thank you Stuart - very clear...makes a lot of sense.

    Cheers,

    GG
5 posts, 0 answered