We are pre Go-Live and currently have 3 (offsite) consultants and myself working to get all our customizations finished before Go-Live January 1st. We are currently on Epicor 10.2.300.0. I did a test with one of the consultants and we found that more than one person can work on a customization at the same time without a hiccup (error or warning message) and that essentially the last save wins. So for example person A starts working first thing in the morning on a customization for Inspection Processing. Person B adds a few bound controls to the Inspection Processing UI over lunch and saves their work. Person A saves their work at the end of the day, and it essentially wipes out whatever person B did, with no message to let anyone know what just occurred. It hasn’t happened yet, but with all that is going on right now, it could and this is one of my biggest fears. I am currently handling this by creating customizations by UI and knowing who is working on what UI. I am looking for suggestions as the best way to manage customizations being created by multiple programmers/sources in a more automated way. Though I am not a Git expert, I am guessing that is an option, but a procedural one at best. Maybe something as simple as a BPM that fires when a second person opens a customization and throws a warning “Person A currently has this customization open”?
We handle this with clear work assignments nobody is scheduled to work on the same module
Not ideal but it works. You can also flag a customization as WIP when you start working on it
We rename the customizations with version numbers, before doing any changes. Looking at what is current version used by user, when we make a subsequent change, we update the version number. So the other user can have knowledge of a change currently being happening…seeing the different versions when opening the form…
We then show on the top of the form the version name so we can verify easily the current version used in the menu for the user.
As Jose indicated, job management is a must… We use the Smartsheet web app (https://www.smartsheet.com/)to gather all of our demand changes, versionning, some info about what was changed by who etc…
i run the tracing log and found that method called StoreData run on BO called GenXData writing to an ice table name XXXDef, when saving customization, other method under this BO called when logging on the customization under developer mode, but all writing to this table.
so if i were you i would try to create a UD field boolean flag on that table (default value as false), then create data BPM to call and check this flag on the DB table at any (tt) record update status,
if flag is true on the DB, then raise an exception to stop users from logging to this customization.
if false go ahead and allow users to carry on working and force update the flag to true on the DB while a user still working, as post processing method BPM will force clear it after saving the customisation. this should allow one user only to work on a specific customization at one time.
Note: using [Db.Validate(); txScope.Complete();]
again i have not tried this before, but i think giving this a try will close the gap of human mistake of using third party app not linked directly to Epicor user activity, and solve the issue of overlap different customization names/numbers on the same BO.
What you need is a Scrum Board where all tasks are outlined with the name of person working on it and the status. That will eliminate all duplicate efforts and assign responsibility also.
For all operations, I recommend this. When you release a customization change with a change to the in-system name, you need to also update the menu item customization references, but it forces a new download of the form on client machines, which is much better than hoping the user’s cache gets cleared.
When feasible, I’d recommend this:
Advanced: What you may want to work toward in the long term is a source control repository outside of Epicor ERP that will help to flag and manage the current version of the customization so that no work is lost. Companies with high technical maturity with this process may suggest using branching within source control, which can also assist in merging changes made by different developers. This involves the making changes in their branch, then “Forward Integrate” merging the shared branch into their branch to resolve possible conflicts, then “Reverse Integrate” merging the local branch into the shared branch.
Here’s a quick note on development cycle branching in a source control system:
Diagram is from a Microsoft paper on TFS branching strategies.
I should note that in my experience working with various companies, I don’t usually get to the branching and merging level of technical maturity, opting to simply use the check-in, check-out functionality of a single set of objects in a source control repository in working with small teams.
Thank you all for the quick responses and excellent suggestions.
@josecgomez - Agreed this is best way to manage and know who is working on what. When you say “flag a customization as WIP”, is that something I can do within Epicor, or are you saying to do this just from a external Project Management viewpoint?
@Hogardy - I have already created a “base” customization for each UI that has been customized with version number. Ex: InspectionProcessingCustomizationv1.0.0. I am spending enough time developing that managing all of it is the rub. I am just wanting a more automated catch-all in case I mis-manage something, or someone does something out of their scope.
@josephmoeller - Advanced. Yes, this looks exactly like the Git environment, which would be a whole new learning experience for me. I will probably implement some form of Git in the future.
@A.Baeisa - This may be exactly what I am looking for as a more automated “when all else fails” solution. I will try to test this today and post back if it works. Thanks.
@Vinaykamboj - I am only familiar with Scrum/Agile from research and never been in an Agile development environment. I agree that a Scrum board or some form of Project management area would be very helpful.
Yes there is a WIP checkbox on the customization save screen
@josecgomez - OK I found the WIP checkbox on the “Save Customization As…”. In testing it doesn’t seem to do anything more than provide a visual that the customization is being worked on? I checked the WIP checkbox and saved the customization with a new name. I then went in and opened the same customization from another user context. It allowed me to make changes and save without error? If I just click the Save button, it does open the “Save Customization As…”, but unless I am missing something it is still just a visual as far as I can tell.
It also doesn’t make it available to assign in menu maintenancE but yes a visual
You can use that as a checkout if checkbox is checked then someone is working on it … Easy way to not step on each other
you may need to cater for multi Save actions, may be some thing like show message to user every time he/she hit Save to ask if he finish his development on this Customization as ‘Yes’ will clear your flag and ‘No’ put the flag to true -if it is not- then raise another exception to stop the ‘Save’ action.