Anyone utilizing a structured development life-cycle with changes/customization to ServiceMax.
Where I am we currently have 3 developers supporting Salesforce(sales) and ServiceMax(Service).
Current cycle is simple but could use some improvement.
Currently we have 2 development sandboxes that we build in and move changes from them to production.
Generally one sandbox is for normal development with frequent releases the other is for projects that run weeks to months.
Some of us use eclipse with Salesforce plug in other use simple text editor for apex.
ServiceMax Licensing and
ServiceMax Meta data has shown to complicate usage of sandboxs and sandbox refreshes and life-cycle tools.
We believe we should move to utilizing more usage of tools like:
Perhaps Salesforce DX
When looking at these tool I feel like I'm rediscovering the wheel.
Does anyone have a more elaborate development life-cycle that work for them that there willing to share.
Hi Jeff Mueller,
Were you able to bring the ServiceMax objects to version control (GIT)? I am not a ServiceMax Expert. I am a DevOps Architect and we are trying to work on Continuous Integration and Delivery for all our projects and ServiceMax seems to be one of that. The first step to do any automation is to version the code. We are stuck as we are not able to find a way to version ServiceMax object. I have been searching for the solution and do not find any post related to version control for ServiceMax. This is the only post I saw that is related to what I was searching for. Any information you would be useful for us. Your help is much appreciated.
Thanks in advance.
Objects such as the work order object/table can be pulled with Eclipse or SF migration tool.
But you may be talking about SFM’s and other ServiceMax Objects.
I have not found an good way to do these but here are some things I’m doing and thoughts on.
1. You can use the Service max migration tool and move the selected objects into a file instead of another org.
a. This file then could be put in version control but not a CI
b. The export is a zip file of many json files that I assume are exports from ServiceMax config tables.
i. They are not easy to identify what they are for, but I have not spend much time reviewing the files.
c. When using the exported file to do an import you have these issues:
i. You can not choose what items in the file you want to import.
ii. I have found that when using a file it does not always import all the objects. IE things are missing when I use the file for import. I do not have this issue if I use the Servicemax migrator and go directly from org to org.
1. Fyi I have been considering putting in a ServiceMax ticket for this but have not.
If you would like more details about these processes let me know.
Thanks for your response Jeff Mueller. The reason to version are as below:
1. To have a proper branching and merging in place helping different developers working on it and also to resolve the conflict when the previous release defect is fixed in parallel to current release development
2. To bring in Code quality checks early in the cycle.
We would like to version only the customized objects in ServiceMax. From your response above, I see that it is possible to pull the customized code. Please let me know if my understanding is not right. As mentioned earlier, I am not a ServiceMax developer, but DevOps Architect helping the team to build a Continuous Delivery pipeline.
Hope using Eclipse integration to BitBucket I would be able to get the code to the version control.