RH2020 Publishing in a Multi-Author Environment

[RoboFan]

BACKGROUND

3 tech comm staff running RH2020 update 3.

RH projects reside in Git repos in the cloud.

RH output is Responsive HTML5, Azure_Blue.

Output is posted to an internal MS IIS webserver, for consumption by co-workers. 

Output is currently generated by any of the 3 tech comm staff (after pulling latest files from Git repo) and then posted via standard Windows Copy/Paste to webserver. 

ISSUE

Looking to take advantage of RH's publish feature so we can do away with copy/pasting an entire output. Also want any of our 3 tech comm staff to be able to generate output and then publish it. 

SCENARIO

On Monday, tech comm staff John generates output and publishes from his machine/instance of RH and RH project. On Tuesday, tech comm staff Mary (on her machine/instance of RH) pulls the latest version of the project from Git (it includes John's changes from Monday), edits a topic in that project, then generates new output, and publishes.     

QUESTION

During Mary's publish operation, will RH "determine" that just the one topic she edited, changed and post JUST that topic, or will the fact that she generated output from a different machine, cause RH to think that a bunch of different topics (in addition to the one topic she edited) have changed, and therefore publish those as well (even though nothing content wise changed in all those other topics/files)?

SUMMARY

In a multi-author RH environment, will "publish" ignore differences in machines/locations where output is generated and only add/replace topics that actually changed/added? Or should we use a centralized "build machine" to handle generating output and then publishing it?

[Jeff_Coatsworth]

It's always been my understanding that Publishing will only transfer over what files have been changed in the output - & it clearly can't just use the date stamps on the output files, because then everything would be uploaded regardless of content changes each time output was generated. I'm pretty sure that what instance of RH generates the output has no impact on what's copied up on publishing either.
Are you finding it acting in a different way?  

[RoboFan]

That would be my hope. I've not been able to test it, but I'm hoping to roll it out this weekend. I wanted to know before I do, if my expectation/understanding is accurate. I looked at a couple rhlog.txt files but it appears they store indecipherable (to me) SHA values.

[Peter Grainge]

There's an overriding issue here that I have raised with Adobe.

Not using source control I have found that when I publish to a server with Update All disabled, it still seems to take as long as when it's a full update. I therefore have doubts that the process is properly differentiating between changed and unchanged files. It is an issue that is listed to be investigated.

Throw in different machines and source control and it likely adds a new dimension to the issue.

I think for now as long as the process works you may just have to live with the time taken.

________________________________________________________
See www.grainge.org for free Authoring and RoboHelp Information

[Jeff_Coatsworth]

The important part is that the source control check outs/ins work - a little more time transferring the output files is not the worst thing to happen.

[RoboFan]

Appreciate the insight, Peter. That's a bummer - but also confirms my trepidation.

Our team is still primarily working from home. Copy/pasting an entire output every time we release uupdated content (several times per week) is incredibly slow over VPN. (1 project is manageable, but updating more than that on the same night is painful (our output is merged output consisting of 11 child projects and over 6k topics so if we're making project-wide changes, it's really bad).) I was hoping that "publishing" might speed up the process while we continue to work remotely. Also, I don't have concrete evidence, but I fear copy/pasting an entire output can sometimes result in a handful of topics/files not pasting correctly (home wifi hiccup? personal ISP hiccup? who knows?). I have observed 6 topics not making it over after we copied/pasted updated content a previous day (and those are just the ones I found - with so many topics, I can't go checking every folder). I thought that perhaps if the publishing function was transferring less files, the there'd be a lower chance of an issue resulting from wifi, VPN, ISP hiccups.

Btw, copy/pasting is MUCH faster to our internal web server when we're physically on-site, but we generally update our output after business hours. So I was also hoping that publishing might provide the first step towards automating nightly output generation and publishing.

[Peter Grainge]

At one time Publish did not support SFTP so I had to seek a third party tool and found SyncBack Pro.

With the output published on one machine I then ran a sync with the server and SyncBack only uploaded what had changed. I can't say how well it will work in your more complex scenario but I think it's worth a try.

Google SyncBack Pro. There's a free trial and each licence is £50 so not a deal breaker.

________________________________________________________
See www.grainge.org for free Authoring and RoboHelp Information

[RoboFan]

We're (I'm) pushing out a full update to all 12 of our merged projects this Sunday (1 parent, 11 child). Due to the VPN issues and the scope of this update, I'm going to be on-site. For those reasons, I was also going to use the opportunity to deploy publishing. In your opinion/knowledge/experience with the function's issues, is it worth it at this point (updating all 12 projects via publish), or am I at risk of breaking something or creating further issues - Sunday, further down the line, etc. - BEYOND length of time (e.g., loss of data/content)?  

Thanks again for the feedback!

[Peter Grainge]

Publish does work, the issue is whether or not it is publishing all the topics regardless of whether or not Update All is selected. Thus it is a matter of the time it takes rather than what it updates.

You have a VPN in the mix and I don't but I haven't seen any reports of that causing issues with publishing. That said it doesn't mean no one has had an issue. If you are looking for guarantees, none given. 

________________________________________________________
See www.grainge.org for free Authoring and RoboHelp Information

[Amebr]

This post suggests the MD5/SHA text file is used to determine which files need to be copied up to the server (based on MD5/SHA difference?). It's pretty old, but if similar files are being generated, then I assume the functionality is essentially the same. I don't know enough about MD5/SHA to know if that means all files will always be published when different users do the publish, though.

https://community.adobe.com/t5/robohelp/notorious-bsscftp-txt-files-any-way-to-get-rid-of-them/m-p/8...

I haven't migrated to New UI, but one thing with a merged project to be careful of, based on RH11 and earlier.

At various jobs with merged projects, we have generated all our projects into the merge structure so we can see how everything fits together as we edit. If we published the parent, then all the children, in whatever state on our C drive, were also published.

So if John had made changes in Child 2, but I still had an old copy of Child 2 on my local disk, then the old copy would be published when I published the parent.

So I do not set up publishing on the parent. Instead, when I need to publish the parent, I manually copy just the parent files and folders (select everything except the mergedProjects folder).

However, this is with Classic and I haven't tried it with New UI, so you would need to do some testing.

Also, if you always get the latest and generate all projects before you publish, then this won't be a problem for you.

[Peter Grainge]

The problem of the parent generating all the child projects is one I too have seen in Classic but the new UI does not have that problem.

________________________________________________________
See www.grainge.org for free Authoring and RoboHelp Information