Most software applications include an “undo” feature. It’s great, isn’t it? You can change something and if you don’t like the result, simply undo it. How cool is that!
Wouldn’t it be equally cool if software development teams could implement changes to software applications and if the users don’t like them, undo? This would be a little tougher than just clicking an undo menu item but it’s not that hard — if you plan ahead.
A good version control system like Git or Subversion can help but isn’t essential. If you plan ahead, the undo capability can be fairly simple.
As each sprint begins, examine the sprint backlog and ask the team a question.
“How will we undo this sprint if some or all of these changes flop or are rejected by the business?”
There’s no standard answer. How undo gets done depends on the software implementation. Here are some techniques I use within Salesforce.com. Hopefully, they will give you some ideas for your projects.
- Create or refresh a sandbox (an isolated development environment). This gives me a snapshot of the production code and the database schema. There’s no ambiguity. I know exactly what I’m working with.
- Make backup copies of anything you intend to change. Eclipse makes this easy for Salesforce.com whether you use a version control system or not.
- Implement database changes as needed. I try to avoid changing existing database fields and prefer to insert new ones and copy over the existing data if needed. That way, I reduce the risk of breaking anything. I can always delete unused fields after deployment.
- Define new VisualForce pages and Apex classes as needed. I usually implement skeletal pages and classes to start. This gives me software components to see and interact with. Then I build out the pages and classes iteratively to provide the features requested.
- Modify existing VisualForce pages and Apex classes as needed. Making these changes undo-able is trickier. Isolating changes within code modules is always a good idea. (They are easier to remove.) I’ve also used parameters to control whether or not a feature is active (sometimes on a per profile or per user basis). This makes it easier to turn features on or off in production.
- Finally, create or modify any validation rules or workflow rules associated with the new feature(s). I sometimes include profile or user information within the rules so I can control system behavior based on user privileges.
That’s it. I can make whatever changes I want and back them out quickly and easily, if needed. (Yes, I’ve had to do that on rare occasions.) The key ideas are: 1) isolate changes to the greatest extent possible, and 2) use run-time parameters to control feature activation. Give it a try.