Reduce Project Risk: Get knowledge of the environment where the system operates.

One of the most “technical” challenging phase of a project is the transition of code from the development environment through the integration and test environments into production with Installer Packages.


Within most companies developers are responsible for the creation of Installer Packages. The MSI’s are created on development workstations, which have local admin rights and most often some exotic settings and applications. For sure, completely different than the production environment. With all the risks and extra work during deployment and testing.


In a more ideal situation, packages are automatically generated during the build process. A much better situation, but also harder to accomplish. The process is completely automated and can be reproduced. But still it doesn’t reflect the production environment, which still result in project risks.

When development doesn’t know and can’t test against real production environment settings we get some challenging risks.
For example how should we test non-functional requirements like: availability, scalability, capacity and performance? and how should development write installation instructions and operations guides (deployment, backup, recovery, weekly tasks) and probably there will be some problems with security and the configuration of security settings when deploying to production.

So, a better way should be when development knows the production environment details.
Operations can describe every detail about the environment, but, you also can use Team Architect’s Logical Datacenter Designer [LDD].  


Logical Datacenter Designer is used to create models that describe the policies and logical structure of a datacenter, including servers, firewalls, communication paths, security constraints, and other configuration requirements that affect the deployment of application systems into a datacenter.

The Logical Datacenter Designer is a design tool..! so don't tease operations with Visual Studio, you will get the most strange reactions when you do that. You better could use the IIS Settings Import Wizard and ask for the credentials.



Anyway, finally you will end with a more "in control" deployment process.
Development knows the production environment, so they can design and build there applications with the real settings in mind. With this extra knowledge Design For Operations and Design For Deployment are much more realistic. Development can give operational management the right information how the solution need to be managed and monitored which will result in lower project risks..!


Some extra things we can do to automate this, "Enable ALM by Automation":

  1. Generate installer packages from the Logical Datacenter Designer, System Designer and Application Designer. We've got all the information we need! [see DSL 4 WiX]
  2. Generate MOM packages and manageability models [see Design for Operations on Codeplex and this post]
  3. Create WorkItems in TFS.
  4. Create Threat Models with the "Import Deployment Report" feature from the Microsoft Threat Analysis and Modeling Tool and create WorkItems from there.
  5. ...


some additional information:

  1. MSDN Virtual Lab: Architecting Connected Systems: Logical Data Center
  2. MSDN Virtual Lab: Architecting Connected Systems: System Designer
  3. Kevin Sangwell Blog: Bridging the Gap between Development and Production [very good information about this topic]
  4. Gearing Up for Modeling, Microsoft Style, April 01-2006

Add comment

Şarkı Sozleri