Best Practices Using NoetixViews Workbench for Customization Management – Part 1

By Bryan Walton, Director, Engineering at Noetix

From the time we introduced NoetixViews Workbench last year, the solution has won several industry awards and been adopted by many of our customers.  Now we have a list of best practices for those using Workbench for customization management.  There is lots of great information here, so we’ve broken it out into three blog posts.  Below, Part 1 discusses several proactive steps you can take to optimize your customizations environment.   We encourage you to contact us at info@noetix.com if you have any questions.  Enjoy!

  1. Use only one environment for your customization work.  Use other environments for test and production.  For example, if you have Dev, Test, and Production instances of NoetixViews:
    1. Use Dev for customizing and adding views.  It will be the source control for your view revisions, ongoing work, fixes, maintenance, etc.  In other words, do all your creative work in Dev.
    2. Create a package in Dev; add the desired customization revisions to it that all make sense as a unit.  Note that you can only stage one package per environment.  You cannot mix and match packages and should not edit them after staging to do a mash up of multiple packages.
    3. Carefully test your customizations in your Dev environment before moving forward.  Dev is the best place for iterative test, fix, and test fix cycle.
  2. Use Test to test your customizations once they’ve passed your Dev testing.
    1. A Test environment should closely mimic your Production environment so that you can see how your customizations will behave when they’re released into the wild.
    2. When the customizations in Dev are ready to move to Test, promote the package from Dev to Test using Manage Packages: Promote. In order to keep your Test and Production instances clean, only revision zero and the packaged revision are promoted from each view – the history, intermediate revisions, and other work are not.  You should use the option in promotion to remove all revisions and packages in the target Test or Production Environments.
    3. On the Target Environment page select the option “Delete all managed views in the target environment.”
  3. Stage and run the installer and views generation from Test.
    1. If there are any fixes or even tweaks to make in Test, you should go back to Dev, do them there, update the package, and re-promote to Test.  If you edit them in Test, you now have two sources of the truth and you have to move those changes to Dev manually. If you use Promote to move them back to Dev, it will delete all your revisions for those views in Dev, as explained on the Target Environment page.  You might forget to move them back to Dev and then you have diverging copies of your view customizations.  In short, you could soon have quite a mess on your hands.
  4. Use Production when your customizations have been tested to your satisfaction and according to the norms and standards of your organization.
    1. Make sure your package in Test is up-to-date, and then promote it to Prod, using the same options as above.
  5. When standing up a new Test or Prod Noetix_Sys schema, to avoid running stage 4 multiple times:
    1. Run stages 1, 2, and 3 on the new schema,
    2. Register the new environment,
    3. Promote to the new environment,
    4. Stage at the end of Promotion, when prompted,
    5. Run stage 4.
  6. Keep your installs folder as clean as possible.
    1. Before you capture the first time, or recapture, determine which scripts are no longer being called and remove them.
0 replies

Leave a Reply

Want to join the discussion?
Feel free to contribute!

Leave a Reply

Your email address will not be published. Required fields are marked *