Я работаю в команде программистов eXtreme и более 7 лет занимаюсь парным программированием в среде Windows. Когда мы впервые начали это делать, кто-то входил в систему со своими учетными данными Windows, и, следовательно, весь доступ к ресурсам домена и, в частности, контроль версий, был бы подотчетен этому пользователю Windows. В конечном итоге мы получили учетные записи для оконных пар для определенных станций (например, pairA, pairB, PairC и т. Д.). Все разработчики знают пароли к этим учетным записям. Ответственность за коммиты (регистрации) достигается путем помещения инициалов программистов в комментарии во время фиксации.
До сих пор это работало нормально для нас, но моя компания в настоящее время проходит аудит ISO 27001, и аудитор отметил это как риск. У меня есть несколько возможных решений, таких как создание парного аккаунта для каждой комбинации пар, но я действительно хотел бы знать, сталкивался ли кто-нибудь еще с этой проблемой и как они ее решили?
Какое решение было приемлемо для аудиторов?
источник
Ответы:
Я бы предположил, что аудиторы предпочли бы, чтобы разработчики входили в систему как сами, а не как «пара», которая имеет общий пароль. Риск должен быть очевидным - разработчик добавляет некоторый вредоносный код как «PairA» и помещает чужие инициалы в комментарии (или вообще не комментирует его). Как вы проследили до злонамеренного разработчика?
Я бы порекомендовал, чтобы тот, кто ведет первым (в сеансе), вошел в систему со своим собственным идентификатором, и пара продолжила помещать оба своих инициала в комментарии - таким образом, код остается прослеживаемым до реального разработчика.
источник
Я бы вел учетные записи такими, какие они есть, обычно за рулем работает только один человек, и даже если другой человек (неофициально) пользуется машиной, вошедший в нее человек все равно должен знать о том, что происходит на его машине.
Checkins все еще будут нуждаться в комментариях, чтобы показать, кем была пара однако.
источник
Вместо создания отдельных учетных записей, чтобы работа не была заблокирована для потенциально отсутствующего пользователя, используйте систему контроля версий. Когда пара начнет работать, создайте ветку задач. Передайте код в ветку задачи при каждом прохождении тестов. Когда задача будет завершена, выполните объединение и закройте ветку задачи.
источник
ISO 27001 или нет, ваша текущая система работает только потому, что вы небольшая компания, в которой существует высокая степень общения и взаимного доверия. Подобные вещи не очень хорошо масштабируются, поэтому вам, вероятно, придется рассмотреть другие варианты в будущем.
Создание отдельной учетной записи для каждой возможной пары кажется еще менее практичным: вам потребуется 90 учетных записей для группы из 10 разработчиков, и каждый из этих 10 разработчиков должен будет знать 9 различных комбинаций логин / пароль.
Единственное практическое решение состоит в том, чтобы использовать отдельные учетные записи, как предлагали другие, и отслеживать личность второго человека в паре каким-либо другим способом (комментарий в коммите контроля версий, поле в системе отслеживания ошибок и т. Д.).
источник
Ради Пита, пусть ведущий член пары берет кредит / ответственность за толчок / фиксацию. В следующий раз другой участник поедет. «Водитель» не будет делать ничего, с чем он не согласен с вторым пилотом.
Программирование - это совместное усилие. Нет программирования на 100% индивидуально. Не нужно быть привередливым, желая отразить, что данный пуш / коммит был сделан Томом и Гарри, а не только Томом. Преимущества парного программирования стоит игнорировать этот нюанс.
Аудитор прав, «пул» счетов следует избегать.
источник