Difference between revisions of "U.s.oo.o/Planning/Site/CM"
DrewJensen (Talk | contribs) m (U.s.oo.o/Planning/User services CM moved to U.s.oo.o/Planning/Site/CM: document structure) |
(→Configuration Management) |
||
| Line 15: | Line 15: | ||
[[User:DrewJensen|Drew]] 00:14, 10 September 2007 (CEST)I would vote for doing our own on the new server. | [[User:DrewJensen|Drew]] 00:14, 10 September 2007 (CEST)I would vote for doing our own on the new server. | ||
| − | + | [[User:TerryE|TerryE]] 02:38, 15 September 2007 (CEST) -- Configuration management of a COTS based configuration is slightly complicated in that the live build is a blend of a package at a given version which is a single CI; its deployment script which is another CI and the individual patches and their deployment scripts (which in the case of a patch, the easiest way to implement this is as a bundled script so there is only the patch which is a say a tarball with a mandatory install.sh element), so the each individual patch is a CI. Even so we still get into impact analysis PCMs and regression testing if we need up the base package version. We should also use a basic ITIL compliant administration model here. | |
Latest revision as of 00:38, 15 September 2007
Configuration Management
Use of vc tool on the new server or use of existing vc repository on an existing server?
Development environment:
- Where ( for example, should we keep a separate directory structure, database on the server for one dev/testing implementation.
- Steps to move from the dev / test implementation to the live implementation
- What should be checked in to vc system
- Any backup steps that should be taken first
- Notifications to users
What about moving things from the a local PC to the site testing implementation?
There is also a cross over responsibility here within the disaster recovery plan - not sure which needs the section. I think there.
Drew 00:14, 10 September 2007 (CEST)I would vote for doing our own on the new server.
TerryE 02:38, 15 September 2007 (CEST) -- Configuration management of a COTS based configuration is slightly complicated in that the live build is a blend of a package at a given version which is a single CI; its deployment script which is another CI and the individual patches and their deployment scripts (which in the case of a patch, the easiest way to implement this is as a bundled script so there is only the patch which is a say a tarball with a mandatory install.sh element), so the each individual patch is a CI. Even so we still get into impact analysis PCMs and regression testing if we need up the base package version. We should also use a basic ITIL compliant administration model here.
Author: wiki page
created Drew 9 September 2007 (CEST)'
Please do not change the logical content of this site without
acknowledge of the author or the UCV Contact list.
