Dogfooding Sitefinity's own releases
It is well known that Microsoft is constantly dogfooding their own products and even pushing out pre-releases of their software to production systems.
However, it does not seem that the Telerik Sitefinity team is currently dogfooding their own Sitefinity releases since the Sitefinity website itself is still running Sitefinity v. 3.7.2152!!
If they were truly dogfooding their own product with each release into a production environment, they would recognize and encounter all of the same issues that their end users and customers are encountering. In addition, it has been nearly 2 years since Sitefinity v. 3.7 has been discontinued from active development so I see no reason why the Sitefinity website itself is not running some version of Sitefinity v. 4.x or Sitefinity v. 5.x.
I'm sure there are good reasons, but certainly one of the problems I've not yet been able to resolve with v4/5 sites, Telerik seems to resolve by running a v3 site - locking down admin access.
It would seem that access to the admin area of the Sitefinity website is secured via IP whitelisting on the IIS server.
This is simple with v3 sites, and I used to do it all the time, to reduce the exposure level.
However, with Sitefinity 4/5, IP whitelisting is something I've not been able to successfully implement.
@MB: Agreed on the whitelisting. It's not straight forward in 4.x 5.x. and I hope it becomes clearer soon. I prefer some other methods to secure it as well.
I would like to join this conversation and shed some light on our dogfooding strategy. We strongly believe that dogfooding is one of the best ways to find out the strenghts and weekneses of our products. While most of our public websites may not be running Sitefinity 5.x we do dogfood the product in a number of other projects. A quick example is that every Telerik division has its own internal product portal running on Sitefinity. Futhermore in the beginning of June this year we have released the fist Telerik product division website running on 5.0: http://www.icenium.com/. This project is currently going through our testing process and will soon be running on 5.1. Apart from this product website we do run a number of other projects on Sitefinity 5.x, a quick list below:
Kendo UI Documentation
Sitefinity & Beyond
Both documentation websites relly heavily on the Dynamic Modules for building help content. Other than those projects we do have a number of other websites in the pipeline - one more conference website, and our own http://www.sitefinity.com/. Expect more news on this matter sometime in mid-September.
Let me assure you that the decision on when to start migrating the existing website to the new version of the product was never a decision based on the quality of the product. There are many other factors that dictate when to start this process. Our priorities so far have been to first cater to the needs of our customers. Furthermore the current implementation heavily relies on integration with external systems used in Telerik, which have been developed before Sitefinity (purchase process, forums, ticketing system, CRM, etc.). Instead of simply creating plugins for those systems for Sitefinity 5.x, we have decided to take a different path. Instead of reffering all proprietary bussiness logic and reffering all custom implementation of those systems in the public site, we are building a service oriented architecture which will allow us to decouple the site from the systems. This path, however also is slowing us down, as we need to first build the new architecture, and then make the site utilize it.
@Dan and @MB, indeed whitelisting IPs using the default IIS functionality is close to impossible with Sitefinity 4.x and above. The reason for this that we do relly on certain services, and route handlers including /Sitefinity in their pat. This however can be achieved with the IIS URL rewriter to crete a set of rules (which will explude service and route paths) and prevent outside users seeng the /Sitefinity login page).
I've actually tried the URL rewriter solution in the link provided, but have yet to get it to work.
I am already using a long list of IIS URL re-write rules (for Google AdWords landing page URLs) and every time I add the type of rules detailed in that video, it generates a 500 forbidden error for whitelisted 'addresses' and a 403 forbidden for eneryone else... i.e. total shut-out.
Something that I do find interesting in the above.
SF 3.7-SP4 (Last 3.7 Service-Pack available)
3.7.2136.2 + RadControls 2010.2.826.35
3.7.2152.140 + RadControls 2011.1.519.140
I don't know about others, but I have customers who refuse to upgrade from 3.7 because it basically does the job for them, but a more recent version of RadControls would be useful. I know I could overwrite the Telerik.Web.UI assembly in SP4, and modify the config file, but then I'm in the dark as to what might break... something that Telerik would seem to have 'dog-fooding' experience with.
Radoslav, I appreciated your post on the status of Sitefinity implementation within Telerik. While I applaud the new sites like Icenium I don't see it as a really good "dogfood test" since it only has about a dozen content items. While www.sitefinity.com runs a 5.x version it also exposes some of the undeveloped sides of the product, like 10 pages of football spam entries that I saw while browsing this forum this evening.
I still see Sitefinity as a work in progress, one with great potential but which still has a way to go to reach the feature set, stability and responsiveness needed. I really do hope that Telerik can deliver on that potential in the future.
A product like Sitefinity is always a work in progress. Perfection is always work in progress especially in the fast changing software world (just think about how many thinks came along - IIS is changing, Azure is changing, new windows server is comming, etc.). Sure telerik can say "we only support windows 2003 and Sql and live hapilly for years but I prefer them to shoot for the moon. It took Edison about 6000 unsuccessful trials to create a light bulb that can be used commercially. It will probably take more to make Sitefinity "the CMS holly grail" but they will make it, you watch. Meanwhile we should carefully test if Sitefinity provides what we need to avoid being disappointed (or disappointing our clients which is even worse).
OK you got me I am a huge Sitefinity fanboy :-).
Heads up :-)
Pavel @ eveliko
I am a bit confused where this thread is going. Are you looking for a large scale site running on Sitefinity 5.x? Or trying to make a case for 3.7? Or simply stating that you won't trust 5.x until a specific site is converted over to it? something else?
I'm not sure if this helps, but we are running Sitefinity 5.0 and have a site with ~350 individual pages and ~1500 additional items in the content libraries, and a couple dozen content editors. We have a dedicated Sitefinity server, and overall it works pretty well and we have been happy. I have quite a bit of optimization and improvement left to do on our own custom templates and modules, but overall the site stays hot and responsive.
Dan, thank you for sharing the experience with your project!
Rick, pretty soon you'll see the new sitefinity.com. As my colleague stated, it's integrated with enormous system, single sign ons, CRMs. We'll make a case study of the project, once it is done. Even all the forums that we are discussing in now, will be migrated to Sitefinity. As I like to say, impossible until it happens :) But it should happen at the right time, when you have so much variables into the equation.
the Telerik team
As part of the case study results, I would be particularly interested in seeing performance comparisons and benchmarks between the current Sitefinity.com site on v. 3.7.x vs. the performance on Sitefinity v. 5.x with none of the modules turned off. I would also be particularly interested in performance results as measured and reported by Windows PerfMon in regards to overall memory utilization, CPU utilization and bandwidth utilization. The exact configurations used in Windows and IIS in terms of Application Pool settings, IIS module configurations as well as things such as overall user experience, comments and feedback from content managers of the system should be incorporated as crucial elements of the case study as well.
This would help a great many organizations achieve similar or better performance with their Sitefinity v. 5.x deployments when migrating from their current v. 3.7x installations. This is especially important since Sitefinity v. 3.7x never had the option to turn off modules, therefore, many of the features/capabilities were always available and ready to use.
You seem to have 2 requests there... one for the case study and one for 'official' benchmarks.