Extreme Programming - Re: Continuous Outegration

Author

Re: Continuous Outegration

Robert Atkins

2004-03-18, 6:53 pm

In article <MPG.1ab3bb4e15895fd498971a@news.noos.fr>, Laurent Bossavit wrote:
> involved, and thus as many different kinds of solutions. "Nice"
> components (dependency is on a single file, such as a JAR file) go into
> a "binary" directory of the version control tool; the file needs to be

That bit is easy... we have lib under version control.

> "Nasty" components (such as Oracle or Sybase DBs) are a different

I've been dealing with this all w

.

Our project team have just moved from the customer site to our office
(yes yes, onsite customer and all that -- but you don't want to go
there). Recent staff movements have made *me* the resident guru (!) and
I've had to set up four new workstations.

Install ATG Dynamo, patch ATG Dynamo, install IIS, install IIS
connection module, configure IIS connection module by tweaking registry,
install server and client certs for IIS. Install VSS client. Configure
VSS client on Novell network with no NT authentication. This stuff is
*very* hard to automate. Some of these things can only be scripted on
paper (especially under rotten environments like Windows).

For the frequency it is done, I think the most practical solution is the
one mentioned upthread: local guru gives setup doc to newbie and says,
"I'll be over in 30 minutes if (when?) it doesn't work". Note that I
don't like this either.

Cheers, Robert.

Phlip

2004-03-18, 6:53 pm

Robert Atkins wrote:

> Install ATG Dynamo, patch ATG Dynamo, install IIS, install IIS
> connection module, configure IIS connection module by tweaking registry,
> install server and client certs for IIS. Install VSS client. Configure
> VSS client on Novell network with no NT authentication. This stuff is
> *very* hard to automate. Some of these things can only be scripted on
> paper (especially under rotten environments like Windows).

I worked a site with a

solution for "virgin release machine" - but not
for warming up a newbie's 'puter.

They ran Linux with a dual-boot. The Linux partitions could treat the other
partitions as data, and copy complete images in. So the Linux side had a
menu of install sets to chose from.

Note that the Law of Pairing requires the newbie to pair the first day, on
communal machines. If they all roll over and one falls out, that will be the
guru, who must now configure a new workstation for himself.

(Rob - I have to ask - have you been the target of much ribbing for all the
"health food" these days that tastes like the cardboard tube from the center
of a roll of paper towels?

(Sorry - I couldn't resist;)

--
Phlip
http://www.xpsd.org/cgi-bin/wiki?Te...tUserInterfaces

Robert Atkins

2004-03-18, 6:54 pm

In article <nb_3c.57802$eG1.35228@newssvr33.news.prodigy.com>, Phlip wrote:
> partitions as data, and copy complete images in. So the Linux side had a
> menu of install sets to chose from.

This sort of thing is much easier (possible?) when you have a Real
Operating System, but often you don't get that choice.

> (Rob - I have to ask - have you been the target of much ribbing for all the
> "health food" these days that tastes like the cardboard tube from the center
> of a roll of paper towels?

Actually, being in Australia I wasn't aware of my more famous namesake
until someone emailed me thanking me for operating on his wife's kidneys
15 years ago. And you've got no idea how odd it is to wake up to a
newspaper headline telling you that you're dead...

Cheers, Robert.

Sean Case

2004-03-18, 6:54 pm

In article <nb_3c.57802$eG1.35228@newssvr33.news.prodigy.com>,
"Phlip" <phlip_cpp@yahoo.com> wrote:

> Note that the Law of Pairing requires the newbie to pair the first day, on
> communal machines. If they all roll over and one falls out, that will be the
> guru, who must now configure a new workstation for himself.

So how do people other than the guru learn how to configure new
workstations?

Sean Case

--
Sean Case gsc@zip.com.au

Code is an illusion. Only assertions are real.

Phlip

2004-03-18, 6:54 pm

Sean Case wrote:

> Phlip wrote:
>
on[color=darkred]
the[color=darkred]
>
> So how do people other than the guru learn how to configure new
> workstations?

Note that the Law of Promiscuous Pairing requires the guru to pair when
configuring a new workstation. Note this is also a development effort -
tuning all the scripts.

--
Phlip
http://www.xpsd.org/cgi-bin/wiki?Te...tUserInterfaces

Robert Atkins

2004-03-18, 6:54 pm

In article <gsc-ADFBCF.23192913032004@nasal.pacific.net.au>, Sean Case wrote:
> In article <nb_3c.57802$eG1.35228@newssvr33.news.prodigy.com>,
> "Phlip" <phlip_cpp@yahoo.com> wrote:
>
> So how do people other than the guru learn how to configure new
> workstations?

When the Guru leaves or is incapacitated, the apprentice guru must
puzzle it out from the available docs.

Cheers, Robert.

Phlip

2004-03-26, 11:50 pm

Robert Atkins wrote:

> When the Guru leaves or is incapacitated, the apprentice guru must
> puzzle it out from the available docs.

Important tip to ambitious apprentices: Make sure your guru has updated the
documents before incapacitating them to take their position.

--
Korax

neurophysical-reeducator

2004-03-26, 11:51 pm

"Phlip" <phlip_cpp@yahoo.com> wrote in message news:<S5e2c.56030$J97.48219@newssvr33.news.prodigy.com>...
> The project's
> eldest guru must pair with the new guy, run the system over and over again,
> diagnose each glitch, and reconfigure it away. This situation resembles
> delaying integration long enough to encounter "integration hell". Instead of
> smooth saling you get dominos of bugs.
>
> Is this a process smell?

Not repeatable. Not spinach.

Kevin Cline

2004-03-26, 11:51 pm

"Phlip" <phlip_cpp@yahoo.com> wrote in message news:<S5e2c.56030$J97.48219@newssvr33.news.prodigy.com>...
> eXtremos:
>
> Suppose your project tests frantically, integrates continuously, and
> releases easily.
>
> Suppose then you hire a new coder, and need another workstation.
>
> Then you have a party. All the source requires 3rd-party libraries, of
> various versions, which must be matched, and these require configuration
> options and scripts installed here there and everywhere. The project's
> eldest guru must pair with the new guy, run the system over and over again,
> diagnose each glitch, and reconfigure it away. This situation resembles
> delaying integration long enough to encounter "integration hell". Instead of
> smooth saling you get dominos of bugs.
>
> Is this a process smell?

Yes. You need to automate this as much as possible, and then
painstakingly document anything that can't be automated. On Linux or
Unix that would be pretty trivial -- you put all the software on a
network disk, and tell the user to add a call to
setup_hairy_project.sh.

> Does it indicate someone should add a motherhood
> story indicating the codebase is continuously outegratable?

> Would an off-the-shelf configuration manager handle it?

On UNIX, yes, practically any configuration manager could handle 99%
of this problem, and you can take care of the remaining 1% by defining
some symbolic links. On Windows, AFAICT, it seems the answer is no,
since every file reference in windows is qualified by some drive
letter that will vary across installations.

> If so, wouldn't configuring
> that tool be a chore each time the team changes a library?

Again, on Unix it's no problem at all. You just change the symbolic
reference to point to the new version, or else just install the new
version in your configuration management system.

John Roth

2004-03-26, 11:51 pm

"neurophysical-reeducator" <n0spaam@yahoo.com> wrote in message
news:967085a1.0403231316.5c969ab@posting.google.com...
> "Phlip" <phlip_cpp@yahoo.com> wrote in message
news:<S5e2c.56030$J97.48219@newssvr33.news.prodigy.com>...
again,[color=darkred]
Instead of[color=darkred]
>
> Not repeatable. Not spinach.

You might, however, like to look at

infrastructures.org

for one way of handling the configuration issue.

John Roth

Sponsored Links