All geek questions in one place

Sitefinity development environment and source code management

There are several requests for which we need permission before buying a license for sitefinity 5.0. I would really appreciate it if I could get answers to these

  • What are the recommended guidelines for setting up a sitefinity project in the source control? If 4 to 5 developers work in a project, what should be the starting point in setting up the source code base? Should every developer create a sitefinity site and database in their dev-box?
  • Is it recommended to install a common database for the sitefinity site, where all dev-machine will connect for development, if not an alternative approach?
  • Is there any available online documentation related to the assembly and release of sitefinity web applications, other than publishing in a visual studio?

Thanks Gaurav

+4
source share
2 answers

We are developing Sitefinity with version 2 with several developers.

To answer your questions specifically:

  • Ask one developer (ideally your lead developer) to create a clean visual studio version of sitefinity on your local computer. Check it in your version control repository and ask each additional developer to get a copy from there. Now you are all in sync.

  • In terms of the location of the database, two approaches work: each of them starts a local database, and in web.config it sets the location of the connection string as . (i.e. locally). Thus, no one should check the web.config file to run it. Otherwise, use a shared development / test server for the database. We found that the easiest way is for each of them to have a local database if several developers are simultaneously working on very specific tasks.

  • I have not seen any online documentation related to building outside the visual studio. If you have a TFS or MS build server, it should also work fine.

In general, there is nothing special about the Sitefinity architecture that separates it from any other .NET / MSSQL solution. Best practices that fall under these technologies are still being applied.

+5
source

My version control experience was one of two options. If you use SQLExpress user instance databases (this is mdf in the App_Data folder), I find that all versions other than this database file and the dataconfig.config file in the configuration folder will allow each developer to run their own copy of the website.

from there you can do some kind of manual database merge or just create a new one for deployment.

This option works best if your developers just work on the features and don’t need to work on a real website, changing the content that should be synchronized.

Alternatively, if they need to work with live content and everything should be the same, create a database on a shared server that everyone has access to and change everything (since the connection string should be the same for both).

This works best if your developers do the job of supporting existing content, rather than creating modules that manage the database (creating tables, columns, etc.), because keep in mind this method, everyone will have access and modify the same database.

Personally, I prefer option 1, because it allows each developer to fully control their environment. the source can then be combined and shaded onto an intermediate server, so that only one instance affects the main content of the site.

I hope this will be helpful!

+4
source

Source: https://habr.com/ru/post/1411946/

More articles:


All Articles