Our development team turned our code over to configuration management this week. It is CM’s job to run the official builds we sent to test. This year we upgraded to new versions for many of our tools. So the build scripts had to be updated. We also have annual changes to the build scripts based on our source code control and other yearly dependencies. The build script updates were performed by three of the developers on our team. That sounded like an upgrade because we only had two people working on the scripts last year.
The main CM guy was about to go on vacation. So he hurried up and tried to build our 5 applications. He had all kinds of problems. And he kept asking for help. I felt bad because this guy is a buddy of mine. So I provided whatever assistance I could. In the end he declared that 5 install packages had been built. Then he left for vacation. I asked one of the script developers to include a new DLL in one of the application installs. This seemed like a good opportunity to see if he successfully did what I asked. I tried to install our application and the thing bombed. I tried some of the other installs and found them lacking. I immediately went and told the software development manager that we were in trouble. He told me to go visit the backup CM guy the next day and see if I could make things work.
So I headed to our office on the other side of town. The backup guy never seemed to have done a build before for our project. So I gave him some pointers. The first build completed but was no good when I tried to install it. The second build completed, and installed, but would produce errors when you try to run the application. I spent a few hours try to debug these build problems. Every time I would fix something, it would uncover a whole set of new problems. This was crazy. As it was getting late into the afternoon, I called the original developers that made the changes to their scripts.
Each guy assured me that they tested the build scripts. The only problem was that they only tested them on their own development machines. It seems that the first guy to test it on a fresh machine was the CM guy. Of course these scripts were not going to work. There were all kinds of problems. Many files required were missing from source code control. Other files were in wrong directories. Crucial steps that the builds need to perform did not work correctly. Other input that the build scripts required were not correct in source code control. It was a miracle these things worked even on development machines.
After a long day with little to no success, I called the software development manager. I told him we were deep in problems. Then I said I was going home because there was zero percent chance of me making these scripts work that day. It was already getting late in the night. The next day the manager called all the script developers to one location and had them trace through the problems. I felt like I got set up. At least do one test in a new environment if you are mucking with build scripts. This should be fundamental.
Newbie Gets Confused
-
A relatively younger developer got tasked with doing some performance tests
on a lot of new code. First task was to get a lot of data ready for the new
c...