This content has been marked as final. Show 7 replies
We have the same issue with the simple file deployer. It refuses to copy certain files however it doesn't give an error. They just continue to show up in the queue. I've found the issue to be related to the total length of the file path. When I change the directory/file names... shortening them... the deployer works. It seems random because it's not related to an individual directory/file name, but the total length... or so I've observed.
We intend to write our own file deployer, but priorities have prevented it... so we have had to make do. It would be nice if Adobe would build a more complete file deployment system included with the CPS... as its one of the more key functions it should be able to preform.
Were using CPS 1.1 on its built in JRUN server. Hosted on a Windows 2003 box. Its the only app on the Box.
The filename length (including full path) is definitely the issue: more than 255 characters and it gets ignored. I figured this out on a Windows 2003 server (see my last post under "dependent files not moving from staging server to production")
Further to that post, I realized that if Contribute users add a link to a file (PDF in this case) by selecting it from the website (using the choose route), it doesn't get added to the XML dependencies file - even though the file will need to be copied from the staging server to the live web server.
I too would like to write my own file deployer, but I'd have to do it from scratch as we don't run ColdFusion. I'd include deployment via FTP, Dreamweaver-like synchronization of all supporting images, css and documents, the ability to apply rules (e.g. all PDFs open in a new window), and logging to a database that included an unlimited number of roll-back versions.
RoboCopy ..... that's all that needs to be said for publishing from a staging server and a prod server.
I may have the opportunity to create a project to write a new file deployer later this summer. We are a .net shop and don't do any CF development. Some of the features I'm looking to build are: Auto, Manual, or Scheduled deployments. The ability to deploy to multiple environments independently... like our Dev, QA, and Production environments. This is in addition to deploying across multiple load balanced servers. I've leveraged the CPS to replace our portal's CMS system and will attempt to extend it to manage content in XML files and Databases. Fun fun.
RoboCopy is a great utility, but is not going to meet all of my requirements. I don't want my users to have write access to my web servers or have my prod support guys needing to be part of a content publishing work flow. I was hoping to find a quick fix for the simple file deployer to hold us over until we can write our own. Oh well.
If and when we are able write a .net/c# file deployer I will be happy to share the code to anyone who is interested. Thx.
We configured Robocopy to not only copy, but synchronize our staging server (golden copy) with the production server. Three times daily, the batch file with all parameters is automatically launched by the Scheduler on the staging server. We have been using this for nearly a year with nearly 100% accuracy. The only gotcha being that occasionally a .LCK with hidden attributes will get published, which won't allow the "real" file to be published. I'm researching this issue now.
Note that we publish only three times daily - you can tweak the frequency with Scheduler - and does not happen when you click Publish in Contribute. When we need something published immediately, we use Dreamweaver - the Local site = Staging server, the Remote site = Production server. Click the "Put" button, NEVER the Checkin button. Only a select trusted few have this priviledged capability, since it require R/W access to Prod.
In reply to Damien's post: this sounds really promising - we're a .NET shop too, though we do all our work in VB. When you start work on your deployer project I'd be very interested in discussing it with you.
Thanks to Snickelgroober for posting the tips on setting up RoboCopy to do scheduled synchronizing. I'll download the utility and take a look. One thing I don't see an easy way around is the need to hold back some files on the staging server: sometimes our users will publish pages that they need to continue working on before they go live.