:: Re: [DNG] Fw: Request for comments…
トップ ページ
このメッセージを削除
このメッセージに返信
著者: Rick Moen
日付:  
To: dng
新しいトピック: [DNG] Responsible Use of Acronyms: was Request for comments - training room
題目: Re: [DNG] Fw: Request for comments - training room
On Tuesday, December 4, 2018, 2:06:17 PM EST, Steve Litt <slitt@???> wrote:

> On Mon, 3 Dec 2018 13:42:36 +0000
> Rowland Penny <rpenny@???> wrote:
>
> > On Mon, 3 Dec 2018 13:22:40 +0000
> > g4sra <g4sra@???> wrote:
>
> > >
> > > Interestingly little mention of workstation BOOTP, NFS Root, Cloning
> > > On Boot. Manually applying CCR's in each training room of 28+
> > > workstations is going to be a pita. No one mentioned the likes of
> > > Puppet, Ansible, ClusterSSH etc.
> > > 
> >
> > This is probably down to the very little information you provided, I
> > also have no idea what 'Creedence Clearwater Revival' has to do with
> > anything we are discussing ;-)
>
> I can answer that. We all figure that someday people won't spout
> uncommon and unagreed upon acronyms. But someday never comes.


For the record, I can confidently predict that the intended reference
was Change Control Request, an essential element of a controlled
environment with complex local configurations and/or locally developed
software. In any well run shop of that kind, any code/configuration
push to production must first be tested in development and sometimes
staging environments, and only then pushed to production.

The steps to be taken get designed as scripted actions (the deployment
procedure) along with equally scripted steps to reverse the changes (the
backout procedure), described on a standard format and circulated to
peers for review as a document called a Change Control Request. When
the CCR has gotten appropriate signoffs (other people being sometimes
needed for that, too), then a rollout time gets scheduled and an Ops
staffer assigned to do it. Both the deployment procedure and the
backout procedure would include test steps required to verify or
disconfirm successful completion. The Ops person carries out the CCR
steps including if necessary the backout procedure, only halting when
the production environment tests as stable.

I worked for many years at a reasonably large firm that ran many Web
sites, and no changes to production of any kind were permitted without
CCR tracking.

As the OP mentioned, running things via CCRs does not _necessarily_
imply use of change control software (Puppet, Chef, cfengine, Ansible,
etc.), though it would be perverse IMO not to use it in any significant
deployment.