Recently I delivered a new version of an application. I tested it by cloning Production data into my development environment. Then I sent the new application out. Another developer peer reviewed the new app. The app would not work in his development schema. It also did not work for our internal testers.
I had committed to a quick release of this application. These testing problems prevented a release. So it was time for me to intervene. The application depends on the database being in a certain state. My own development database was correct. So was production. But the test database was out of sync.
I figured that production gets data when we release database changes to them. So I poured through the database releases from the last year. I found the release that populated the expected records. It apparently had not been run in the test database.
Since the customer needed my fix quickly, I reverse engineered the good database release. A tester acted as a DBA while I gave him directions to bring his database up to date. After that my application changes worked fine.
This turned out to be a database configuration management problem. We need the test database to mimic production. This is a process level problem that needs fixing now. Otherwise I will be back debugging the test environment soon.
Cisco Packet Tracer - I downloaded this software for free from Cisco. From the name "Packet Tracer", you would think this is some type of packet capture/analysis tool similar t...