Altering code on the production system to quick-fix an issue is sexy. Even when you realize it's evil and bad and harmful - your day comes you disregard the details and get it done nonetheless.
Its you that visit the negative side every so often: How can you attempt to fix the disadvantages? Would you use a SVN (...) Server to trace changes around the push machines? Use a job that compares checksums of files and transmits out "remember-you-transformed-this"-Mails? Just place an email around the white board? Sync changes to an improvement server?
Added: I'm guessing like a proven fact that this type of bad practice happens. I'm not thinking about an ideal workflow to avert this. Or whether or not this happens more frequently in PHP or JAVA or COBOL projects. Or perhaps in small versus. large projects. In newbie versus. veteran projects. Or when you get immediately punished with a cosmic entity should you choose it. I'm simply thinking about creative functional tips from people who understand how to handle that type of situation.
Possess a rollback plan just in case the fast fix does not work.
For any website, it might be as easy as copying the entire factor to some backup folder.
Frequently, this entails getting a database script to undo changes produced in database scripts.
Possess a smoke test so that you can tell immediately for those who have damaged the applying.
Do not do it......result in the alternation in source control, deploy for your System Test/UAT atmosphere, test the modification, then deploy to Production.
Otherwise, how are you aware your 'fix' labored?
Funny you need to request, since my boss requested me to create a quick alternation in production just last evening.
Except it had not been as fast and dirty as that which you might be asking about. I made the modification within our development atmosphere first, then went the task utilizing a copy of production data and verified the outcomes. Around the administrative side, I produced a bug ticket to document things i was doing.
Not to mention I made copies from the production code before I replicated the modification in from development.
Regardless of how simple and quick the fix and just how sure you're it's what you ought to do, I think you'll a minimum of made copies.
Make use of a version control system and, for the reason that, possess a 'stable' branch (or make use of the trunk because the stable component). Put essential inside that everything for the reason that branch (or even the trunk) ought to be appropriate for fast deployment at any time. And give a warning that whomever breaks that branch / trunk shall die as well as other painful punishment.
Adding automated testing will even provide you with confidence such things - when the tests succeed, you are able to presume a deploy around the live server won't be any problem. Obviously, it requires a significant large purchase of time (and, consequently, money) to setup this kind of atmosphere (and keep it), plus you'd need to convince the management.
It is also a large plus for those who have an evaluation atmosphere that reacts just like the production atmosphere - same or comparable data, hardware, operating-system, versions of 3rd party software and runtimes, and when your production atmosphere is really a clustered one (multiple webservers, for instance), make certain your test atmosphere has this too - this may be done using virtual machines, if I am right.
Cowboy Coding: http://www.bnj.com/cowboy-coding-pink-sombrero/
Though an interesting appearance it appears a significant approach. By providing this "visual feedback" not just everybody knows, that there's trouble on production, it encourages everybody to enhance the workflow to reduce "pink sombrero" time.