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?
Firstly, communication is always the key here as you mentioned in your inquiry. Whatever communication method works best with your team is always going to be the Grandfather of solutions on how to handle concurrent development changes.
That being said, our company asked our implementer to help us build a major business object called "Blueprint Tracker" accompanied by a supporting business object called "Blueprints" and we have just built upon that as we've gone.The Blueprint Tracker owns Blueprints and allows us to document our releases in real time right in Cherwell.Before a developer will save a blueprint they will first find the appropriate Blueprint Tracker that was already created by the Project Manager or another Developer. If one does not exist, the Tracker will then be created. The tracker will simply outline the details of the Release. In that Blueprint tracker, at the bottom there is a tab that says "Blueprints". This is where we record all of our details about each of our blueprints. This is great for our auditors if they ever need information about any Cherwell blueprint changes we've made, and also for our own records, allowing us the ability to search an object for changes we've made in the past if we can't quite remember what we've done. (which totally never happens 'cuz we remember EVERYTHING right?) Ha.
Example fields we have in the "Blueprints" object are.Blueprint NameDeveloper NameEnvironment Checkboxes (DEV, QA, PROD)Date/Time of Publish.Objects impactedOne-Steps impactedExpressions impactedAutomation Processes impactedScheduled Items impactedSpecial Instructions (example: update security setting for workgroup A, import file B, etc)and a free text Details field.
In addition to this, we hold regular discussions, and will typically ask each other if anyone is working on a blueprint before we start our own.
To help with that, we go to security and view the "View Currently Logged In Users" for DEV and QA before publishing because typically the only people in those environments are our developers. If we see that one is logged into the Cherwell Administrator Module, we simply contact that person to see if they are working on anything that will interfere with what we intend to work on.I hope this provided some insight into how others are handling concurrent development.
One more thing, I'm not sure what version your company is using, but in Cherwell 9.0.1 they introduced a concurrent development feature when you go to publish the blueprint, that allows you to select which version of the blueprint you would like to publish for each object that's touched, best practices documentation for concurrent development, and also a short Video Learning Library video on concurrent development. The documentation can be found HERE.
This is very helpful. Thank you!
Not sure if you know or if it'll help. In version 9 of Cherwell there is blueprint conflict resolution which is meant to support concurrent blueprint development:https://cherwellsupport.com/WebHelp/en/9.1/content/system_administration/blueprints/develop_blueprints_concurrently.html
We run multiple development environments and on some releases have upwards of 15 developers between them.
I would say in order of importance I place the following items when working with multiple people:
Our group if we are developing you are in our chat and communicating withe rest of the developers. It can be a skype group chat, meeting, or other developer tool like slack.
Understanding object overlap is key to managing a large development pool. If you understand the overlap you can mitigate or remove almost all your problems. Items like Stored Values, Counters, items in the (none) association and related objects. Assigning someone responsible for an object and making sure they are aware of changes to that object not only allows you to have the ability to spot overlap, but it also allows you to have a better chance of tracking down a conflict when it happens.
Save your blueprint close your admin client and delete the local catalog files forcing a refresh has cut down our issues by itself by an order of magnitude. We almost never run into an issue with our core team anymore because we follow this practice.
Make sure you timestamp your blueprints and document what you did from a major touch point and focus on documenting the overlap items if you are touching them.
It was mentioned elsewhere here but mApps are a big part of our strategy. We just merged 3 development environments into one this release using this and its important to understand how to leverage them and what caveats they have. Depending on what and how you chose your options for merging it can be a boon or make you cry. Learning the ins and outs of the settings on an mApp wizard can change how you deploy in Cherwell. Make sure you are aware that deleting and mApps don't go along unless you delete through the mApp itself.
On the conflict checker released recently. It will definitely help in the initial environment. Just remember that if you are migrating from one environment to another using blueprints it will fire off quite a bit. We do not use this feature when migrating just in the initial environment.