Defensive code, maintenance and updates

Since we have a full supportdesk at the office. we aren’t responsible anymore for updates, etc. So this actually means we just have tpo focus ourself on just development. Sometimes the suportdesk passes a small problem or site update to us tru. In these causes we have to do the engineering, support will do the S final Sitecore updates/database updates/deployment.
For this reason we have some rules how you should defense your code. The update procedure:
– Update external sources like external databases
– Install Packages with changes in Sitecore
– Full publish Sitecore
– Place new DLLs
– Update configuration files

During this process, everything should work. No yellow errors may appear. So this means we actually always have to check if every item/configValue/field we retrieve, or expect that we should be able to retrieve, should we checked if it’s null or empty. Ofcourse this is always the best way. But when you are developing small pages, with no logic, just binding predefined field-values to label is really fast and easy.
Another thing we have to look at are the changes in templates and masters. You should definitelly track which changes are made and in which order. Sometimes is iusing different packages for templates, masters and items a good idea.

All described above should be done and known by every engineer, altough most engineers think they write defensive code. In reality you will see that writing defensive code isn’t so easy at all. Just try it. Update your development-environment with soem patches on the way described above and lookat the functionality. Is it broken after any of the steps? What did actually cause the problem?

One thought on “Defensive code, maintenance and updates”

  1. I think you are missing an important point. The main problem I see with Sitecore sites when they fail is that an Item is loaded in code but never checked of the item really exists. This causes a NullReferenceException. Which, when badly handled, can cause the whole site to collapse.

    There are a couple scenario’s where this can happen. One of them is with updating the website. When you already copied the DLL and haven’t created the Items yet. The other is when users can delete or rename an item because rights aren’t set correctly. Or even when checks aren’t made on the template for empty fields.

    This is a real problem, for it is hard to find and fixes mostly need a new DLL. Another problem we have is a chicken and egg problem. We made changes in the codebehind and in the ascx/aspx pages. They need to be copied together. This hardly can’t be done without stopping the website in ISS.

    Another usefull hint that I can give to programmers. Never ever put codebehind in a aspx file. I know this is a Sitecore best practice. But this week I found out why. Some code was causing a NullReference, due to incorrect security settings. But the code was in the codebehind of an aspx file. So I couldn’t simple disable it. (I don’t have acces to the webserver myself, couldn’t just upload a new DLL) If the code would have been in a sublayout or rendering. I would just remove the sublayout from the item. Getting the site back up in the air. and then fixing the problem.

Comments are closed.