As developers, I think we’ve all said this to ourselves at least once:
“It’s just a minor change.
It can’t possibly break ANYTHING.”
That’s human nature. We think we understand everything that goes into the issue and we’re sure it’ll be fine. It passes the unit tests and all is good. So, you deploy it up to production. After all, you are repairing an issue with a simple 10-second fix, right?
And then the world explodes.
This is not an optimal outcome…and it gives extra meaning to the belief that everything that gets deployed to production should go through testing. While you might be correct, and that tiny fix to that tiny problem could go smoothly, it’s also possible that you might break the system. And then you get to spend the next who knows how many deployments in an org that would prefer to have been left alone, thank you very much.
So, while it’s a bore and takes more time than it should, slow down and test everything in your Dev sandbox. And then, only after at least SOME testing, deploy the changes to production.
Below are a few common problems that we’ve seen with “spray and pray deployments”:
Problem A: The system falls down and goes boom?
Whatever you put into the org is now causing extensive problems. Now you have to back out the change and then clean the data. This can take days, depending on exactly what you changed. Change some code in a controller in a Visualforce page that nobody uses, no big deal. Change code in the import procedure that processes a million rows of data per hour, BAD! So, your small fix just cost you and your company time and money.
Problem B: Lost in a sea of testing and field requirements.
In staging, you might be able to add a field you missed to the SOQL query. In production, no such luck. Each time you fix a field or change the way the Visualforce displays, you have to complete a full deployment plus unit tests. And most times, it’s the full unit test suite that kills ya. So, if you end up deploying to production even one less time by not trusting that “it’s just a small fix,” you can save yourself a lot of time.
We’ve all made mistakes. We learn things. We figure out that it’s never really a small fix. It always needs testing. At Red Argyle, we have already been through and seen the results of not testing properly. We’ve evolved our processes to minimize unexpected results. All deployments, no matter how small, are executed as part of a deployment plan that includes communications with the client, acceptable deployment timing, and testing both prior to and after the deployment. We’ve found that this helps us avoid the problems that occur with hasty deployments.
Now that the lesson is over, it’s time to fess up. Go ahead and share an embarrassing memory about one of those times you trusted too much and skipped the testing. Believe me, you’re not alone.
