The job of portal developers are to develop for portal, right?  But what happens when they can’t develop?

What Happened

A major insurance company had a portal administrator who was adamant that nobody other than him could touch any of the environments in any type of administrative capacity, even basic portal administrator in a development environment.  So, what happened was anytime developers wanted to do something in the shared development environment such as update a portlet, create a page, create a url mapping, assign a custom unique name, deploy a theme, etc they had to rely solely on the portal administrator.  So, here is an example of what would happen when a portlet needed to be deployed.

1. Submit portlet WAR to system admin
2. Wait
3. Test the portlet and get bugs
4. Wait for system admin to set portlet settings to resolve the problem
5. Something else goes wrong
6. Wait for access to log files
7. System administrator deals with production problem
8. System administrator goes home for the night
9. Wait some more
10. Get access to logs
11. Suspect portlet settings in 4) were not applied correctly
12. System administrator blames the code and sends log files to developers again
13. Come to find out, system administrator did not set the portlet settings correctly
14. And it just keeps going on…..

Choosing a Global Software Development Partner to Accelerate Your Digital Strategy

To be successful and outpace the competition, you need a software development partner that excels in exactly the type of digital projects you are now faced with accelerating, and in the most cost effective and optimized way possible.

Get the Guide

To complicate matters even worse, this company used an offshore development model so at times an entire development team became idle for a majority of a work shift.

What Should Have Happened

Developers not having access to the development environment is crippling to productivity.  There are really some best practices which must be followed or development efficiency will be cut to its knees.

• Establish rules for deployment.
  • Have standards and guidelines in place for portal administration (custom unique names, url mappings, naming conventions, etc.)
  • An automated build and release tool will be extremely helpful, especially if it is tied to source code control
• Establish times for deployments and server restarts
• Provide portal administrative access to developers in development
• Provide administrative access to leads and architects in test/stage
• Provide read access to all developers in all environments
• Provide access to log files to everyone in all environments
• Bring portal system administrators into the loop.  They are part of the team and need to help out, not just throw suggestions over the wall

I can’t count the number of times I’ve seen stand offs between portal administrators and development teams when it comes to problem resolution.  Administrators blame the code and developers blame the configuration.  When neither party have insight into what the other is doing, it becomes a never ending troubleshooting circle and everyone just gets frustrated.  Everyone needs to work as a team and this includes providing developers access to their own development environment.

Previous Installments

1. Where’s My Homepage?!?
2. The Business Asked for It
3. Methodology for Methodology’s Sake
4. The Never Ending Strategy
5. I Built It But Now I Can’t Support It
6. We Can Get Big ROI From a Portal
7. Is Best of Breed Always Best?

Join us this month on Wed, June 29th for our Perficient Perspectives webinar in which we explore the 12 Things You Shouldn’t Do on a Portal Project in depth.  More Info / Register