|
 The conversation usually starts with my boss calling me into his (or her) office and asking me to help out with a task that has suddenly popped up. Usually, it is a matter of a developer leaving the organization and I need to quickly take over the build engineering that had previously been handled by this developer. If I am lucky, I may get a few minutes to shake hands with the departing colleague (luckier still if I can exchange links via my linkedin profile). But, more often than not, I just inherit a build that may or may not be in very good shape.I have had this experience many times and sometimes it is pretty straightforward and I can just add it to my standard build processes. Other times, it feels like I am taking over a large deck of cards assembled into a very fragile three story house. Taking over someone else’s build can be tough in the best of circumstances, but getting your arms around the “hand-me-down” build can be especially painful. Here are some steps that you can take to tame the savage build “tiger”. The first step is to isolate a computer and a computer account that can currently run the build right now. This may be tricky because many companies disable an account immediately if someone resigns. The next best thing is to get your friendly systems administrators to help you isolate the user’s environment. In Unix or Linux this might mean that you get a copy of the .profile, .bashrc or other files that setup the runtime environment. Environment variables can significantly alter the behavior of a build and many developers are not very well disciplined in terms of putting all of their dependencies into the scripts themselves. You might also ask the SA to help you “su” into the account – just to get the environment variables. (Make sure that you get permission from your boss for this, because it is pretty common for companies to have very specific policies restricting use of an employee’s account – after he or she leaves.) “su’ing” into the account means that you run for a short time as if you had logged into the account (and then can capture the environment variables). Next make sure that you are working from a stable baseline of the code and that you ascertain all of the build dependencies (e.g. compiler versions). In taking on someone else’s build, I have often found scripts that had hardcoded references back to the user’s account or permission issues that can be tricky to discover. The best approach is to have a way to run the build without any changes and then migrate the build to another machine and user account. In a perfect world, the buildmeister provides an independent build service just to guard against these types of problems. In my world, I often have to jump into these fires and do my best to tame (and ideally simplify) the “hand-me-down” build. Bob Aiello is the Editor-in-Chief for CM Crossroads and a Software Engineer specializing in Software Process Improvement including Software Configuration and Release Management. Mr. Aiello has over 25 years experience as a technical manager in several top NYC Financial Services firms where he had had company-wide responsibility for CM, often providing hands-on technical support for enterprise Source Code Management tools, SOX/Cobit compliance, build engineering, continuous integration and automated application deployment. Bob is the Vice Chair of the IEEE 828 Standards working group (CM Planning) and is a member of the IEEE Software and Systems Engineering Standards Committee (S2ESC) Management Board. He is a long standing member of the Steering Committee of the NYC Software Process Improvement Network (CitySPIN), where he serves as the chair of the CM SIG. Mr. Aiello holds a Masters in Industrial Psychology from NYU and a B.S. in Computer Science and Math from Hofstra University. You may contact Mr. Aiello at raiello@acm.org or link with him at http://www.linkedin.com/in/bobaiello
Set as favorite
Bookmark
Email this
Hits: 3785 Trackback(0)Comments (0)
|
TrackBack URI for this entry
Subscribe to this comment's feed