« The Top 5 Build Process Mistakes | Main| IT Labor Shortage in the United States? Or Self-Serving Myth? »

A Recommended Development Environment: Part Two


Bookmark : del.icio.us  Technorati  Digg This  Add To Furl  Add To YahooMyWeb  Add To Reddit  Add To NewsVine 

In my last post I discussed a recommended development environment. In this Post I will discuss moving code from Dev to Test to Production.

This applies to either the source code being in an NSF or an NTF. For this discussion we will assume a NSF. This does not account for any workflow or approval system being in place, so we assume it has been approved.

This is a list of what should be done to the application before it is moved to Test/QA:
  • Create/Update a template(NTF) with the latest design from the development NSF
  • All development-only design elements should be disabled/removed from the template
  • All Scheduled agents should be configured to run in the test/QA environment if needed
  • Recompile all Lotuscript
  • Sign all design elements with an ID appropriate for QA
  • Move the design to the Test/QA server
  • Set the template ACL to give administrators and server’s only accesses to the NTF, Developers have no access
  • Refresh/Replace design on the Test/QA NSF
  • Notify users it is ready for testing
Once testing has passed and the design is approved to move to production, the following needs to happen:
  • All Scheduled agents should be configured to run in production
  • Sign all design elements with a corporate singing ID that is in all User’s desktop ECL
  • Move the design to the production server
  • Refresh/Replace design on the production NSF
  • Notify users it is ready for use

    Now this process needs to be repeatable, error free, and not have to be dependant on any one person to have value.

    Sounds like a good idea for a tool!

Comments

Gravatar Image1 - We built one in 2003. It's the cornerstone of our application development/maintenance.

Gravatar Image2 - I think you need a couple more steps when moving into production.

* Backup the production system so if the move into production fails you can go back quickly and with the least pain. (This has saved me more than once.)

* Before notifying users that it's ready to use you should do some final testing to see if it works in production like it did in QA. After all, it is a different environment and you did have to at least reconfigure the scheduled agents. (This has bit me a few times.)

Best regards,

Rob:-]

Gravatar Image3 - You must also fix any embedded views to other databases.

Gravatar Image4 - @1 That is good news! I hope it is working well for you

@2. Good points, a rollback mechanism is paramount to a successfully build process.
Production testing is a key element of a deployment process so I agree as well. Thanks good feedback

@3 Embedded Views!!! One day I hope to be able to use them as you described, I stay away from embedding views from other db's for that reason, But you are correct that they must be changed when you move to production.

Good feedback everyone keep it coming

John


Post A Comment

:-D:-o:-p:-x:-(:-):-\:angry::cool::cry::emb::grin::huh::laugh::lips::rolleyes:;-)