XCentium Blogs
Technical
5 Keys to a Good Sitecore Dev Environment
With over six years of Sitecore consulting I have had the opportunity to see many different environments. I have seen simple setups where it is just you or a couple other developers. On the complete opposite side of the spectrum I have seen setups in larger companies where you are in a group part of a much larger team possibly spanning hundreds of other developers. One thing they all have in common though is that if you do not have a good structure in place for a development environment you will be left spending countless hours fixing problems, band-aiding projects, redundant code, and ramping up new developers. When I am tasked with setting up a new environment the things I think about are: how can I make this simple enough for new developers to pick up on, how can I structure this well so other developers follow the same pattern, what techniques can I apply to make troubleshooting simple, and how can I make it easy to expand upon. Below I have laid out five keys to a good Sitecore Development Environment. These are not the only keys to making a good dev environment, and depending on your own company practices they may vary a bit. But none the less I hope this is seen a good starting point for you to build on. Also note that most of my experience is around using TFS for source control. 1. Seperate Sitecore and Code - Nothing makes me more squeamish than coming onto a project where development source is tightly grouped with your Sitecore environment. Not only does an independent work space from Sitecore look a lot cleaner it is also much more practical for future upgrades and builds. I look at my custom code as a "plug and play" to a Sitecore environment. I want my code to be dropped on my dev Sitecore as well as integration, QA, CMS, and Production environments. I want to do this in a way that I know that everything in my solution is exactly what I need for my site to work against a fresh Sitecore install. In order to do this you will want to take advantage of Visual Studios publish tool. Place your source in separate folder, I use "Workspace", and your site generally under "Inetpub". Then create a publish of your project to the inetpub location. Furthermore working with this process you are already half way to creating a build on other servers because you know exactly what is in your solution is what needs to be built over. This might seem like an extra hassle, specifically when working with html / css that does not require a build, but it is something you hardly notice after a while. Publish runs a build first so you can skip that step. Publish is also smart enough to move over only changes. So if working only with css for example, your app pool will not refresh. You also cannot simply debug, but instead have to attach your debugger to the w3wp.exe processor. Overall, in my opinion, the idea of a clean solution separated from Sitecore out weighs any the extra hassles you are not used to. 2. Multiple projects - A good solution will have a handful of projects even if the site is small. Consider future expansion and how awesome your boss will think you are when you don't have to go back and rework a bunch of stuff to make room for the new site. First create a primary web project for your site. I like to use periods in my project names so that I can identify the primary project name and their purpose. Your website project could be as simple as "Project.Web" . This will hold your layouts, css, js, images, and other elements that will be present in the Sitecore web site and should be considered the project that is most commonly built to your Sitecore environments. Secondly consider creating a "Project.Sitecore" project. This will hold your app_config config files and modules. This should be considered more of a global project. Something that handles customization to the Sitecore environment and stays ambiguous to all websites installed to your Sitecore instance. Finally most certainly create a "Project.Data" project. This will allow you a data layer to tie your custom development to. More on the data layer later. Depending on your requirements other projects may need to be added. A helper class library or a web service API are two examples of potential candidates for new projects. Basically anything that can live as a reference to your main "Project.Web" project can fall under this classification. 3. Data Layers Win - Nothing spells a new developer or a quickly done project as finding something like "currentItem["MyFieldName"]" in source code. All though this approach is very much supported it can spell disaster down the road. Imagine if you have a very complex site with a hundred different sublayouts, classes, and renderings. The request comes down to change "MyFieldName" to "FieldName", now you get to have the fun of doing a slow manual find and replace. You can't just run a find and replace on the whole solution and be done because your might end up replacing all those references to "ThatFieldName" as well. A data layer allows you centralize those references so one simple change will expose all problems on your next build. As for what to use as a data layer, this is more up to you. I have used GLASS as well as ClassySC. My preference has been ClassySC due to its slick interface in Sitecore Admin to build class files for you based on configured templates. However it is no longer supported. Alternatively you can just build your own data layer, which is not a terrible idea. It might be a little more up front time intensive, but allows you greater flexibility. I would say if you are going the manual route to stay simple and build up slowly from there. Don't paint yourself into a corner with complexity that you don't really need. 4. App_Config Everything - Back a couple years ago when we were doing migrations from Sitecore 5 to Sitecore 6 one of the biggest headaches was the Web.Config. If you have spent any time working with Sitecore you know how expansive Sitecore's Web.Config file is. It is not a fun time to find yourself digging through it line by line trying to find all the customization made to the Sitecore instance. So with Sitecore 6 their team came out with this great concept of the App_Config folder. Basically anything in the Web.Config can be overridden with config files placed under the App_Config. This allows developers to see a simple list of exactly what has changed. Use this for everything. Even the very basic single <site tags should be overridden here. This allows you to drop your list of config files into a fresh install of Sitecore with no concerns of something lost along the way. 5. Document Setup - While setup is still fresh in your mind, create a list of steps a new developer should follow. Be specific. Include things as simple as "download from source control and map to workspace folder X" and "create IIS site with host name Y". Place them in the order that logically makes sense. The order you would follow if you had to create the new environment. In most cases you will have a list no more than a dozen items long. And this list will be spelled out in a way that even an intern fresh out of college would understand what to do. At the end of your list include common issues the user might come across. Like forgetting to allow read / write access for Network Service on the data folder, forgetting to place the license file, or an install that is specific to your dev environment. Overall this will reduce your dev environment setup from an all day affair to something as little as an hour. I like to keep my install doc in source control and update it as things change or someone hits a problem that I had not accounted on. It is ok for one person to hit a problem and have to spend a couple hours figuring it out. Not so much if the same troubleshoot scenario occurs for a dozen developers. In Summary - I hope these key points help. I don't lay claim to having all the answers, and every project presents new scenarios no one can anticipate for. I go into each project with these key ideas and an open mind to adjust to the requirements needed.
