............................... Date: Tue, 02 Mar 1999 16:46:40 Who: Tim Conrow Subject: ops, dev tst and int, oh my! Original file: /home/tab/tim3.t ............................... From listmaster Tue Mar 2 16:46 PST 1999 Received: from castor.ipac.caltech.edu (castor [134.4.10.10]) by chomsky.ipac.caltech.edu (8.8.5/8.6.4) with ESMTP id QAA25803; Tue, 2 Mar 1999 16:46:34 -0800 (PST) Received: from nijinsky.ipac.caltech.edu (nijinsky.ipac.caltech.edu [134.4.50.105]) by castor.ipac.caltech.edu (8.8.8/8.6.4) with ESMTP id QAA03154 for ; Tue, 2 Mar 1999 16:46:35 -0800 (PST) Received: from ipac.caltech.edu (localhost [127.0.0.1]) by nijinsky.ipac.caltech.edu (8.8.5/8.6.4) with ESMTP id QAA11595 for ; Tue, 2 Mar 1999 16:46:40 -0800 (PST) Sender: tim Message-ID: <36DC8670.EA2634B5@ipac.caltech.edu> Date: Tue, 02 Mar 1999 16:46:40 -0800 From: Tim Conrow Organization: IPAC/Caltech X-Mailer: Mozilla 4.06 [en] (X11; I; SunOS 5.5.1 sun4u) MIME-Version: 1.0 To: WIRE mail list Subject: ops, dev tst and int, oh my! Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Content-Length: 3858 Status: R I've decided to try conveying what I had in mind when I implemented the delivery process we're using now. Let's try a specific scenario: Imagine the mission has been underway for a week and in that time we've been using code out of so_ops and now Russ says "I have a great improvement I'd like to make in wireguidestars." Question: What should happen? Answer: A delivery of everyone's latest code should be made to so_dev and Russ can deliver his new wireguidestars there once he has unit tested it and the CCB has approved. Rational: Now everyone can test their code and other people's code out of the "DEVelopment" delivery in so_dev and eventually be satisfied that the code there is a stable, beneficial improvement over what everyone is using for operations in so_ops. Others can also deliver updates to so_dev once the CCB has approved and the delivery is coordinated with me. These can be unit deliveries (i.e. everyone doesn't have to redeliver). Question: Then what? Answer: To get Russ' improvement into so_ops the CCB must approve a complete redelivery to so_ops. Once they approve a time can be chosen that will not interfere with operations and a delivery to so_int is made and tested. Once the testing is successful, a delivery of the SAME code can be made so_ops and users will begin using it for operatoins. Question: Why was the delivery to so_int necessary? Answer: Suppose that Frank made a small change to his code that never got delivered to so_dev and is untested, but he forgot about it. If we deliver the latest code straight to so_ops, his new change will go in untested. The INTermediate delivery allows users to look for such problems by delivering everyone's latest code all at once to so_int. Question: So what's so_tst for? Answer: so_tst is the wild west of development. The CCB holds no sway and developers cannot expect stability. It provides a place to test code in the presence of other dependencies without having to go through the CCB or any formal deliveries. Question: What's with these 'tag' thingies? Answer: Tags are the way all or part of an old delivery can be resurrected. When all source code is saved under a unique tag for each formal delivery, if a new delivery goes bad, we can retreat to any previous delivery we need to in order to recover working code. Today's delivery (SOrelease-2-3-eject) for example required Yi Mei to recover an old planquery delivery for a special purpose. Question: Do we always have to do full deliveries instead of unit deliveries to so_ops? Answer: Full deliveries are safest because they've traversed the full gamut of testing: unit test -> CCB -> so_dev -> test -> so_int -> RTB test -> so_ops. But if we're in a hurry the CCB can approve emergency unit deliveries to so_ops. These still need to be tagged so the new code can be recovered, but without destroying the previous version under that tag. This can get confusing, which is why full deliveries are better, but it can work OK if it's necessary. Question: Why does a user have to redeliver even when they haven't changed code? Answer: Code often contains internal references to other parts of a delivery Question: What about contingency X, Y, Z, ... ? Answer: As with any system, we can decide on a case by case basis how to deal with exceptional circumstances. Don't let that confuse you with regard to how things work in the normal case cited above. This hectic pre-launch time has been almost nothing but exceptional circumstances, as well as a steep learning curve for many users, leaving many people confused. Please review in your mind the normal scenario played out above in an attempt to understand how things are supposed to work and what int, dev, ops and tst are for. Please ask any questions you still have. -- -- Tim Conrow tim@ipac.caltech.edu work:626-397-9578 fax:626-397-7354