He estado trabajando en un equipo de programación eXtreme y haciendo programación de pares durante más de 7 años en un entorno Windows. Cuando comenzamos a hacerlo, alguien iniciaría sesión con sus credenciales de Windows y, por lo tanto, todo el acceso a los recursos del dominio, y más específicamente el control de versiones, sería responsable ante ese usuario de Windows. Finalmente, hemos evolucionado para tener cuentas de emparejamiento de Windows para estaciones de emparejamiento específicas (por ejemplo, pairA, pairB, PairC, etc.). Todos los desarrolladores conocen las contraseñas de estas cuentas. La responsabilidad de los commits (check-ins) se logra al poner las iniciales de los programadores en el comentario durante el commit.
Hasta ahora, esto ha funcionado bien para nosotros, pero mi compañía actualmente está pasando por una auditoría ISO 27001 y el auditor lo marcó como un riesgo. Tengo varias soluciones posibles, como crear una cuenta de emparejamiento para cada combinación de pares, pero realmente me gustaría saber si alguien más ha encontrado este problema y cómo lo resolvieron.
¿Qué solución fue aceptable para los auditores?
fuente
Respuestas:
Asumiría que los auditores preferirían que los desarrolladores inicien sesión como ellos mismos y no como un "par" que tiene una contraseña compartida. El riesgo debería ser obvio: un desarrollador agrega un código malicioso como "PairA" y pone las iniciales de otra persona en el comentario (o no lo comenta). ¿Cómo se rastrea al desarrollador malicioso?
Recomiendo que quien conduzca primero (en una sesión) inicie sesión con su propia identificación, y la pareja continúe colocando sus dos iniciales en los comentarios; de esa manera, el código sigue siendo rastreable hasta un desarrollador real.
fuente
Mantendría las cuentas como están, normalmente solo una persona está conduciendo, e incluso si la otra persona usa la máquina (no oficialmente), la persona que inició sesión debería estar al tanto de lo que está sucediendo en su máquina.
Sin embargo, los registros aún necesitarían comentarios para mostrar quién era la pareja.
fuente
En lugar de crear cuentas separadas para que el trabajo no esté bloqueado para un usuario posiblemente ausente, use su sistema de control de versiones. Cuando un par comienza a funcionar, cree una rama de tarea. Confirme el código en la rama de tareas cada vez que pasen las pruebas. Cuando la tarea esté completa, vuelva a fusionar y cierre la rama de la tarea.
fuente
ISO 27001 o no, su sistema actual solo funciona porque es una empresa pequeña donde existe un alto grado de comunicación y confianza mutua. Ese tipo de cosas no se amplía muy bien, por lo que es probable que tenga que considerar otras opciones en algún momento en el futuro de todos modos.
Crear una cuenta separada para cada par posible parece aún menos práctico: necesitaría 90 cuentas para un grupo de 10 desarrolladores, y cada uno de esos 10 desarrolladores tendría que conocer 9 combinaciones diferentes de inicio de sesión / contraseña.
La única solución práctica es usar cuentas individuales, como han sugerido otros, y rastrear la identidad de la segunda persona del par de otra manera (comente en su confirmación de control de versiones, campo en el sistema de seguimiento de problemas, etc.).
fuente
Por el bien de Pete, deje que el miembro conductor de la pareja tome crédito / responsabilidad por el push / commit. La próxima vez el otro miembro conducirá. El "conductor" no hará nada en lo que no esté de acuerdo con el copiloto.
La programación es un esfuerzo de colaboración. Ninguna escritura de programación es 100% individual. No hay necesidad de ser fastidioso queriendo reflejar que un empuje / compromiso fue realizado por Tom y Harry y no solo Tom. Vale la pena pasar por alto los beneficios de la programación de pares.
El auditor tiene razón, se deben evitar las cuentas de "grupo".
fuente