"Julie Rudinski" <julier@techapp.com> wrote:
>
> I was wondering if I could get some input on how everyone manages their build schedules.
>
> Currently we have a development branch which all the work is done on. The developers check in their code when they are finished and when it comes time to build I pick up the latest elements on the development branch. This has caused a few problems with files not being checked in, and developers not testing their code.
>
> I want to enforce a more "strict" policy. My idea is as follows:
> All changes to the code are related to a software change number and I have a script prompting for the SCR# upon check in. An attribute is then placed on the element. <This is the new part --> I want the developers to submit the SCR# with a listing of all changed files (I have a script for this, they just need to run it). Then I can build based only on the submitted SCR#'s.
>
> Unfortunately, the developers are adamantly against this idea because it requires them to do extra work (running a script) and remembering to submit their SCR's. (since I said non submitted SCRs would not go into the build).
>
> So I am back to square one, building the latest elements which I do not think is adequate procedure.
>
> Does anybody have any suggestions?
You might have them buy into a zero-failure policy for the scheduled
builds. (Your Q/A department might help apply the necessary pressure
here.) Once that's done, state the conditions you require from them
to assure meeting that policy. Make it clear that violating the
requirements will interfere with your ability to do your job. Supply
the necessary tools to help them meet the requirements; the developers
will probably have their own requirements to interface to their process.
Then insist that they use the tools and don't accept anything handed to
you outside the automated process.
It sounds like the tools are already in place, and all you need is the
buy-in. If their only objection is that they don't want to invoke one
more script, then they may be in need of an attitude adjustment. (Have
your management apply one, if that's all it is.) If their objection is
that there are already a lot of steps involved in the hand-off and they
don't want yet another one, then maybe some of the steps can be
automated some more.
'Course, the trick is to present the whole thing with a spin that will
convey some benefit to them and opening the post-development process for
review, rather than appearing to impose structure upon them for some
hidden agenda. Developers don't tend to take "you don't need to know
that" as an answer to the "why" question.
I've been in a similar position in the past, where some development
groups insisted that checking in code (and maybe applying a label) was
sufficient for a hand-off. After explaining the requirements and the
process, and implementing (in an integrated manner) a bunch of stuff
that assisted their everyday life (e.g. triggers that updated state of
bug reports upon checkin, and updated them further upon hand-off),
the process became very successful. (Course, it helped to have a
director on my side, too.)
-- The CEO of my employer requires me to include the following notice in my signature:* This message is intended only for the use of the Addressee and may contain information that is PRIVILEGED and CONFIDENTIAL. If you are not the intended recipient, dissemination of this communication is prohibited. If you have received this communication in error, please erase all copies of the message and its attachments and notify us immediately. --- Paul M. Sander +1 650 261 5174 | To the medieval era's literate few..., the BroadVision, Inc. | turn of the millenium held a particular alure. 585 Broadway | After all, with the stroke of a quill, the Redwood City, CA 94063 USA | world went from DCCCCLXXXXVIIIJ to...M. | -- Rachel Emma Silverman, Wall St. Journal - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
This archive was generated by hypermail 2b29 : Sun May 06 2001 - 00:23:25 EDT