Our company has been using Cherwell for a couple years, but generally speaking the majority of the development has gone through a single developer. As the usage of Cherwell grows, so does the level of development work. We are in a position now where we will need to add more full time Cherwell developers.
When we've done work in the past with having multiple developers, there has always been the risk of stepping on each others work by overriding changes due to publishing a separate blueprints that overlapped in various objects. We realize communication is a key piece to making sure things are done in proper order and we limit the scope of what's included in the blueprint.
Does anyone have some advice or best practices for how to handle Cherwell blueprints when you have a team of developers making changes?
Record somewhere the contents of your blueprint (which objects, definitions like one steps, forms etc were being modified), the purpose of the changes, etc.
I personally create a 'Blueprint Documentation' lookup table with fields for the blueprint name, status (environment it's been published to, such as whether it's made it to prod or not), and a rich text details field to hold the description.
When I'm ready to save a blueprint, I first go to this blueprint documentation table, select it, and hit 'Edit Data'.
Then I add a new record. In it I record the name that will be the name for my blueprint, and copy that blueprint name. I'll paste this into the save dialog later so they match.
I then write a detailed-enough description of what I'm doing so that someone else, or myself later on, could review that entry to identify what's being done in the blueprint.
This level of documentation helps you to see what other blueprints are open / active and haven't made it to production yet, and allows you to review them to see what's being done in them so you can see whether or not you're going to conflict.
The important step here: if you're working alongside someone else, then when you go to start working on something new, take a look at that blueprint documentation table to see if there's anything new there, and if there is, take a look at it to see if you might run into conflicts with it.
This will make it easier for you, but depends on whether or not the developers involved document out the work at a detail level that allows you to spot / identify those conflicts.
This also lets you see easily whether these blueprints have made it to prod on the prod environment, because there will be lookup table entries for each blueprint that makes its way over. You can easily compare that table between environments to see the difference of which items haven't been moved.
Hope this was a helpful idea for you.
This is helpful. I would be curious to know if anyone else out there has other ideas too.
Doug-Robinson... is your lookup table only maintained in the production database? In other words, if you create a new blueprint in a test environment, do you register that blueprint in the production lookup table?
Thanks for your suggestion!
Actually, I maintain the table on Dev.
You may want to periodically export the contents of this table and update them on Prod so that the information such as status, etc is the same, or just clear out the table entirely, at points when you're going to refresh your dev environment from PROD.
Because at these points you're environments will be in sync.
You could try to maintain this in prod if you'd like; I personally just do it on Dev as it's somewhat simpler in my own use case.
On my own system, I use row images for a green checkmark to indicate if something's made its way to prod, a pause symbol to indicate it's on Dev but not prod, and an exclamation mark icon to indicate it's something I rolled back. This makes it really easy to skim through the list and find what's pending a migration to prod - the pause symbols.
mApps are your friend also :)
Do care to elaborate? Are there specific mApps out there that handle team development situations or help manage blueprints? Or are you suggesting to create a mApp that does what Doug proposes above?