[development] Workflow: staging server, source control, and the files directory

[Brian Vuyk]

 > Also, we run into the odd issue where files uploaded by developers on 
thier local copies conflict with files uploaded on the staging server 
(test.txt, anyone?).

To clarify on the above - developers don't add files to git on their 
local copies, but a test file will sit in the developer's files 
directory until manually deleted. If a file with the same name is 
uploaded to the canonical server, and then pushed to git, the developer 
will need to resolve the conflict before he can merge the latest updates 
with his local site.

On 11-02-18 11:41 AM, Brian Vuyk wrote:
> Ah, I misunderstood.
>
> We take it on a case-by-case basis.
>
> 1. The imagecache directory is always excluded, as those are 
> automagically regenerated anyways if they don't exist. We also exclude 
> the 'js' and 'css' folders, as putting the aggregated js and css files 
> in git is pointless.
> 2. We generally exclude the files directory altogether, and just put 
> up with broken images on our local dev environments.
> 3. If absolutely necessary, we may rsync the files directory down to a 
> dev environment periodically.
>
> We have on occasion tried to keep small copies of the files directory 
> in git, but we run into problems where nodes are deleted on the site, 
> and Drupal deletes the corresponding file from the filesystem. 
> However, having not been removed from git with 'git rm <filename>', 
> someone has to push the filesystem changes with 'git add -u' to make 
> the files directory sync properly. Also, we run into the odd issue 
> where files uploaded by developers on thier local copies conflict with 
> files uploaded on the staging server (test.txt, anyone?). This often 
> needs sorting out...
>
> All-in-all, it's extra work with little extra gain, other than prevent 
> some broken images or file links on the non-canonical copies of the 
> site, which can be fixed as needed by rsyncing the files directory 
> down to the non-canonical development copies.
>
> In short, I keep all the site code in git. For anything that's not 
> code (or part of a code package, such as theme or module images), I 
> try to leave out unless there is a good reason for inclusion.
>
> Brian
>
>
>
> On 11-02-18 11:18 AM, Andy Fowlston wrote:
>> Brian wrote:
>>>>    From a db point of view this sounds very similar to what we do. 
>>>> Could you elaborate on how you keep the files in sync?
>>> Keep which files? The database exports?
>> Sorry, no not the database at all: I'm wondering about any content 
>> related files in the files directory (I presume you use source 
>> control for everything outside the files directory?).
>>
>>> We look at it this way - staging is the canonical database. All config
>>> is done on staging, never in the developer-specific local environments.
>> Yeah, that's how we're doing things at the mo. I'd like to move more 
>> (ideally all) of the config to source files, but we're not there yet.
>>
>> Thanks,
>>
>> Andy
>>
>> . . . . . . .
>> Andy Fowlston
>> +44 (0)20 8747 5068
>> andy at pedalo.co.uk
>> Skype: andy.pedalo
>> www.pedalo.co.uk
>>
>> This email is intended only for the above named addressee/s. This 
>> email may be confidential or legally privileged. If you have received 
>> this email and you are not a named addressee, you must not use, copy, 
>> distribute or disclose the email or any part of its contents or take 
>> any action in reliance on it. If you have received this email in 
>> error, please email the sender by replying to this message and delete 
>> it from your system. All reasonable precautions have been taken to 
>> ensure no viruses are present in this email.
>>
>> pedalo limited cannot accept responsibility for loss or damage 
>> arising from the use of this email or attachments and recommends that 
>> you subject these to your virus checking procedures prior to use. Any 
>> views or opinions presented are solely those of the author and not 
>> necessarily those of Pedalo Limited
>>
>> Please consider the environment before printing this email
>