This gets my vote for the best post of the month if not year on that list. Thanks Scott! ;-)
--DD -----Original Message----- From: Scott Francis [mailto:scott.francis@;newisys.com] Sent: Thursday, October 17, 2002 1:51 PM To: Ant Users List Subject: RE: Looking for a Build Philosophy Ok, there have been a lot of decent comments coming from the mailing list but let me take things to a little higher level view. 1) First off without managerial support you will not be able to achieve any type of build management. If you have developers who are used to doing things a certain way (being however they feel like doing it that day), you are going to be very hard pressed to get them to change. That being said, if you can get a change in place you must also have a system in which to enforce and in some cases punish those that are violating the structure. Without that good luck. Have developer performance reviews be negatively affected by habitual build breakers. 2) All code must be properly built and unit tested prior to being checked into the tree. This should usually consist of taking a fresh pull of the code base and overlaying the changed code (it's amazing how over people forget that they changed these 1 or 2 files (especially header files) and do not catch it because it "worked on my box" in their development environment). 3) Create a nightly build process. This is one of the most valuable tools that you have. Testing and QA teams can update their image from successful nightly builds. Unsuccessful nightly builds can be given back to the developers to determine why this was done and what the necessary fix is. 4) Have a separate CM/Build person who is also responsible for creating the development and release process. By doing this, you are have someone who will be willing to make the "unpopular" but "correct" decisions about how things should be done. Developers notoriously do not like creating Unit Test plans or Release Notes. Forcing this as exit criteria from the development and entry criteria into the testing process helps grease these wheels. 5) Constantly look for ways to optimize and automate the process. I personally like to use an iterative approach with my duties. Usually I'm walking in as a configuration mgmt role that they have no semblance of a process. Triage is a highly effective skill when it comes to this. First thing I always do is automate the build. Then throw it into a nightly. Then look for inefficiencies within the build tree or directory structure. Next round two of automation (automated testing/deployment). All the while constantly writing reams and reams of approach doc and process doc in order to create the foundation of what I'm trying to get done. As the system becomes more and more automated...and the documentation on the process gets more and more verbose, your job becomes infinitely easier. New developers can just RTFM and become product members of the development community. The automated processes make your life easier and give you more time to continue to tighten down the hatches and explore new technologies that might make your role even more fun and rewarding. 6) If you are the build manager...make sure you never let anyone know how much you like your job. Most people in the organization take pity on us because they don't think we enjoy our jobs. Truth be told, I've had more fun in CM then I ever thought possible. It's a very flexible role that allows you coding, process, and personal interaction on a day in day out basis. But at the same time, I'm more than happy to hear people lament on how awful my job must be and how they are so happy that it's me an not them in the role :) Scott -- To unsubscribe, e-mail: <mailto:ant-user-unsubscribe@;jakarta.apache.org> For additional commands, e-mail: <mailto:ant-user-help@;jakarta.apache.org>
