2009-01-13 11 views
7

¿Tiene en cuenta toda la administración de activos al planificar su solución de control de origen? Por ejemplo: imágenes, enlaces externos, contenido, especificaciones y datos? Sé que hay suficiente con lo que luchar para que el control de la fuente funcione de manera efectiva, pero a menudo veo una buena gestión de la fuente, pero la manipulación manual de los otros activos relacionados.¿La administración de activos es un superconjunto del control de origen?

(Agregado) Esta pregunta se inspiró en la stackoverflow Podcast # 36 http://blog.stackoverflow.com/2009/01/podcast-36/

Respuesta

2

donde trabajo tenemos todos los activos relacionados con un proyecto de control de código fuente, documentos internos, documentos de la API de terceros, código, base de datos SQL , contenido, etc, todo el shebang.

También ponemos a disposición documentos comerciales tales como especificaciones, planes de proyecto (sin servidor de proyectos) a través de herramientas de colaboración como Sharepoint para el personal que no desarrolla.

3

Hay algunas líneas entre Administración de contenido, Gestión de configuración, Control de código fuente y controles empresariales normales (es decir, SAS-70, controles SOX).

Las dos son distintas, no existe una relación de superconjunto/subconjunto.

Tiene información de la empresa y tiene la infraestructura para procesar esa información.

Información de la empresa son datos (no procesados); esto a menudo se divide entre Administradores de contenido y Bases de datos relacionales.

  • Content Management es una aplicación que usted compra (o extiende). Maneja información "semiestructurada" y "no estructurada". Por ejemplo, imágenes, enlaces y "contenido". Algunas personas lo llaman "Gestión de activos".

  • RDBMS es una aplicación que usted compra. Contiene información estructurada.

Los controles Ordinary Enterprise deben cubrir todos estos datos de "producción": contenido y RDBMS. Si no lo hacen, ninguna cantidad de administración de contenido o software RDBMS ayudará.

Infrastucture es en gran parte el procesamiento (no datos). Debe aplicar la gestión de la configuración como una disciplina. La gestión de la configuración incluye todos los parámetros de configuración en tiempo de ejecución, configuraciones, archivos y otras cosas, además del código fuente.

El control del código fuente y su configuración forman parte del procesamiento del activo de información empresarial.

que sugieren que se centran en la gestión de configuración - código fuente, ajustes, parámetros, parches, etc.

contenido, al igual que los datos en una base de datos de gestión, es responsabilidad de los usuarios, no a los desarrolladores. Los técnicos proporcionan los RDBMS o herramientas de gestión de contenido. Pero la gente técnica no se responsabiliza por el uso de la información (los usuarios finales son dueños de la información) y pueden hacer lo que quieran.

La gestión de contenido (o "gestión de activos") será manual. Puede comprar herramientas, pero los usuarios necesitan desarrollar sus propios procesos para usar esas herramientas. Y siempre parecerá manual.

+0

¿Podría decirme si interpreté correctamente su terminología en esta otra pregunta de SO (no relacionada) http://stackoverflow.com/ preguntas/440409? – VonC

+0

Creo que hiciste un buen trabajo respondiendo esa pregunta - la subversión no funciona bien para r Datos del usuario final "Contenido" o "Base de datos". Lo que esta pregunta llama "Gestión de activos". –

+0

Genial. Hago un montón de "gestión de configuración" y un poco de "gestión de activos", pero no sabía esa terminología exacta. De ahí un +1 a tu publicación muy informativa. – VonC

2

En la empresa en la que estoy trabajando, como desarrolladores estamos de acuerdo, todo lo que cambia durante el ciclo de vida de nuestro (s) producto (s) y es manipulado por diferentes personas debe ser alojado dentro del sistema de control de versiones. Repasé esa discusión varias veces con los diferentes departamentos y siempre terminaba en 'Suena bien, pero las personas ajenas al desarrollo no pueden manejar los sistemas de control de versiones'. Entonces no tenemos especificaciones, etc. bajo control de fuente. Peor aún, tenemos partes del código, p. java-resource-files editados por no desarrolladores, que supuestamente no pueden trabajar bajo control de código fuente y por lo tanto nos vemos obligados a verificar los archivos, enviarlos por correo electrónico a traductores, editar estos archivos, enviarlos de vuelta y verificamos el resultados en sc otra vez (pero probablemente han trabajado en ellos mientras tanto :-(y fusión) ... que en realidad es la versión corta de lo que realmente sucede (incluso MS-Excel está involucrado).

Entonces, mi respuesta es 'Sí, todo debería estar bajo control de fuente', pero nada más que código lo hará.

Cuestiones relacionadas