Portal / Content Management Development

Over time, the concern about proper development practices has repeatedly risen on development of portal and content management pages. The development process of doing 'everything' in dev, then deploying it to a test environment, and then having it deployed to a production environment once it has been signed off by QA.

I must admit that I have been in the 'developer' camp for a long time. It wasn't until about a year before I came over that somewhat of a light clicked on for me for developing portal/content management sites. The concept of code migration doesn't totally apply.

In order to understand 'code' migration, you have to define what 'code' is. In my opinion, 'code' in this sense is anything that is run server side. In otherwords, if the 'code' has to be compiled or run on the server, then it needs to definately follow the proper development process.

The argument can be made for defining code as opposed to content. However, in portals/content management applications, content can be defined as basically everything else. In otherwords, we are opening up the application to allow end users the ability to input content; HTML, Javascript, Images, text, add new pages, new navigation, links, and more. So it makes sense to me that the 'content' doesn't need to follow the same process of dev > test > production. We cannot expect our end users (content contributors, site owners) to follow such a lengthy approach.

The argument that I hear over and over again about not allowing this to happen is that the environments will get out of sync. This is a fact! In a portal environment, the environments will get out of sync. Content will be managed in one environment! You can only mitigate the consequences of developing in a portal. There are several ways to do this. One that I would suggest is that eBusiness try to make similar changes to the same files in each environment, for example if we modify a master page in production, make the same change in the other environments.

I really feel strongly about not managing content in seperate environments. I also have lots more to say on this subject and have only lightly touched general issues surrounding reasons to do this and reasons not to do this. I am interested in hearing your comments.