We've all heard the term 'Best Practices'.
It's a 'black and white' term.
Not to be interpreted. Seems like we do interpret, when it suits . . .
even recently, and I quote "it's okay to develop live, just don't make a mistake" . . .
Let's work through the obvious - and some not so obvious - points to consider.
Technical Reasons.
File Corruption.
You may not have actually seen this happen, but I can confirm the 'warning' that it's possible to 'hose' a hosted file if you loose connection while finalising schema changes - which actually happened this one time when - I was watching another Developer (so not me, honest) change a field calculation over a VPN, and to have the VPN drop out just after hitting enter, and you guessed it, the file would not open again.
And in this case, due to the size of the system - which was the 'justification' for doing the live update - down time was 48 hours, for the backup to be retrieved from the tapes.
I must also add that even if the field change is successful, every single User will have their active tab control reset to the default tab, without warning.
Data Integrity.
Scripts and functions need to be run, at least once, to ensure they actually do the expected behaviour. As the Developer, are you going to perform edits on the LIVE data yourself, or are you going to ask an end User to run your script for the first time. There's even the option of not telling the Users about the change, and 'assuming' all will be well.
And I can personally confirm (yes, me this time) that FileMaker Server can send around 2,000 SMS Messages in under 10 seconds, as that's how long it took me to realised my loop was not exiting correctly, and to stop the Server Side Script from running.
Thankfully, in this case, my script was written in Test mode, so therefore to send SMSs to only 'my' mobile, rather than client data contacts. This is an other 'Best Practice', while writing and testing scripts in your TEST environment, send all notifications to your Developer account, not to the live contact data details.
This technique includes adding the LIVE addresses to the body, so you can see the end result in the context of this TEST notification without actually sending it . . .
Development Reasons.
Workflow.
As 'creative' as we want the Development process, we still need to follow a structure. User requests a change, Developer responses with proposal, User accepts concept, Developer updates TEST version of system or creates a Prototype, User tests and gives feedback, Developer updates, both agree to the changes, Developer moves changes to LIVE system, there should be no surprises. Everyone is happy.
This whole process is 'lost' when the LIVE Server is updated, regardless of how simple a change.
And I do get the ego rush of having a client call for a 'quick change' - you log in remotely, update the field, script, layout, etc. - even while still on the phone. The client thinks you're a SuperStar and that this development platform is great.
FileMaker DMT.
With the introduction of FileMaker 17 and the Data Management Tool, scripted updates with many other functions significantly reduces the downtime and setup for updates.
Currently I have a client with a four file system, that totals out at 4GB that DMT imports into clones in about 10 minutes.
An other client has a 50 file system, totalling over 40GB, that it's his Sunday afternoon schedule to run his own one hour DMT process, utilising a modified version of Productive Computing's Native FileMaker frontend to run the terminal DMT calls - this modified version supports automatic adding a Directory files, in one step.
And yes, in the near future, Clairs are releasing a function of an XML export where we will have the ability to exported our UAT approved changes, to then import into the live system, without taking the system down . . .
Development Experimentation.
Too often, we as Developer will automatically code based on knowledge and experience.
I have found it highly beneficial to attempt at least one alternative method of solving the same problem, applying a new method or technique I have never used before.
User Expectation.
Let's agree we have taken the best steps to set up a structure that we have the workflow that all changes to code, layouts - well any function - are crafted on the TEST system, as we are the professionals they require.
Tomorrow we agree to slip-in a 'quick' LIVE update, as it's just a simple change.
What happens next time - you say the change or improvement needs to take place in TEST, but the User demands a LIVE update?
Summary.
Takeaway.
These are 'Best Practices' for a reason. Everybody ends up with the 'Best' result.
Or do you care to apply your own 'interpretation' . . .