Hello! Sorry for the cross posting but I haven't ...
# sdf
m
Hello! Sorry for the cross posting but I haven't noticed this specific channel so far. I don't know if anybody in the channel is using SDF to deploy projects. Here in Allys we are, but we are also experiencing some problems with large repositories containing hundreds of files (timeout problems, error when calculating dependencies and so on). So we decided, for specific updates as for example a Change Request that has to be tested before on Sandbox and then in Production, to create two separate deploy.xml and manifest.xml for the specific files of that specific change request. We save them in a Folder having the name of the Change Request and use them for the deploy of the specific piece of code when required. What do you think of this approach? It would be fantastic if the usage of specific xmls, other than the standard ones, would be directly supported by suitecloud.
k
We do have something similar to this but we have github workflows setup that use different deploy.xml files when we want to only deploy the files and not the objects.
If you use workflows you could do the same but when you run the workflow have a field to specify the partial deploy folder name and then use that deploy instead to deploy it.
👍 1
w
When we do development on our full main account github repo, we 1. check out a new branch from main 2. do our development together with any deploy.xml changes that apply to that particular ticket. 3. merge it into main through a PR. In that way we have a reference of how the deploy.xml looked for that ticket. Usually the development is incremental with fixes and features all over our customizations that are connected to each other.
💯 1
m
But are you talking only of Suitescripts or do you include in deploy.xml objects too?
w
Both, the change could include changes to either.
m
Ok. And haven't you ever encountered problems with dependencies or with the dimension of deploy.xml?
We experienced a lot of problems if deploy.xml contained many many files.
That's the reason of smaller deploy.xml files, each one dedicated to the specific branch without having to deploy files that are not included in the update
w
We update the deploy.xml in the pull-request to only include the objects that we want to deploy at that time. We never re-deploy our whole suite of customizations, I feel it is too risky.
m
Ok. That makes sense.
k
HAHA when deploying to my SDN account it takes around 30-45 mins
As everything is connected to everything you cant just remove one thing.
I have tried.
m
And you never got a timeout? For me after 10 minutes it stops
k
Yep but in NS it continues if you check the deployment audit trail.
Sometimes though it doesnt time out on client and it completes as normal.
w
If something is dependency, we add it to the manifest
But it probably depends if you have a Suiteapp compared to an Account Customization
k
Yeah we deploy using account customisation as we are stuck with a bundle for now.