Configuring a Sitecore Preview Site for Anonymous Users

In some situations, there is a requirement to be able to preview unpublished content without logging into Sitecore.  Perhaps a marketing director needs to review the page before it launches, or maybe a partner needs to review a press release prior to the official publish.  The traditional Sitecore preview capability forces you to log into Sitecore in order to be authorized to view the content in the Master database.  So how do you get around this?

Mark Ursino, a Sitecore MVP and the author behind the Fire Breaks Ice blog, wrote a great post on the subject: How to Setup a Sitecore Site to Review Content Before Publishing.  The essential setup is that you need a new ‘site’ in your Sitecore configurations that points to the Master database instead of the Web database.

Mark outlines some caveats with the approach:

  • The HTML output caches need to be manually cleared if you’re modifying cached content and need to preview it. This is because these caches are normally cleared on publish. One possible way to get around this issue is to set the size of the HTML cache for the preview site to 0MB, but I have not tried it.
  • If you use Lucene indexes, they will not be updated. This is because your indexes are probably indexing web content and get added during publish operations.

In addition to these caveats, another situation to bear in mind is the use of SSL certificates.  If you have bound your entire site to a particular domain/certificate, you will get SSL errors if you access the site with a different URL.  Remember to setup your site with multiple ports or IP addresses to allow for multiple certificates.  Read more on SSL configuration for IIS here:

Baby Steps to SOA – Step Seven: Centralizing eCommerce

In the continuing Baby Steps to SOA series, we follow Doug and the IT team behind as they take steps to renovate their digital asset architecture. Previously, we introduced the problem and the team, started planning and analysis, decided on some metrics, and refactored the website applications. Most recently, the team has tackled identity management, introducing a CMS, building data services, and now continues by centralizing their eCommerce functionality.

Continue reading “Baby Steps to SOA – Step Seven: Centralizing eCommerce”

Scaled Agile: Bringing Kanban to the Executives

Portfolio KanbanIn my normal cadence, this week would be another installment in the Baby Steps to SOA series.  However, with a few weeks of vacation under my belt, I was not prepared to tackle the important discussion of centralizing eCommerce business logic quite yet.  That being said, my vacation time did allow me to finally finish reading Dean Leffingwell’s Agile Software Requirements: Lean Requirements Practices for Teams, Programs, and the Enterprise. 

The content of the book, along with the content (SAFe), provides a great blueprint for bringing agile mindsets to larger enterprises.  It goes beyond just the problems on the development team and covers all the tiers of the enterprise, including the executives.

Continue reading “Scaled Agile: Bringing Kanban to the Executives”

Risk Management on Agile Projects – The Risk Burndown chart

Risk BurndownFor most small Agile projects, I haven’t needed to track risks as explicitly, since the standard agile structure with impediments identified daily tends to highlight immediate problem areas.  However, for larger projects and for projects working within a more traditional client environment, tracking risk logs and project risk status are very common.

A tool I have been looking at recently is Mike Cohn’s Risk Burndown chart.  It brings the same sort of visualization benefits that our standard agile reporting provides, but also allows for providing risk status on the project.

The chart on its own will not be enough in many cases.  Most groups that want to track risk also need the details of the risks in order to follow up on them.  The burndown chart on its own is great to give a current status, but we need to be ready with the data behind the chart in order to have the group follow up on the risks and mitigate them.  The same article by Mike Cohn explains the concept of the Risk Census which drives the burndown chart, but also provides all the details the Scrum Master will need to explain the risks.

Article: Managing Risk on Agile Projects with the Risk Burndown Chart
Author: Mike Cohn
Date: April 8, 2010