Опросник составлен с целью определения уровня риска, который вызван несовершенством SDLC процессов, применяемых на проекте. Влияние каждого отрицательного ответа на степень риска различна и будет определятся индивидуально. В том числе зависит от контекста проекта (размер, длительность, технология и т.д.)
Причина, по которой вам стоит потратить время на заполнение одна – это возможность взглянуть на положение дел на проекте “со стороны” и определиться с возможными улучшениями.
- VCS
Какая система контроля версий используется (git, svn, hg, tfs, etc.)?
Вопрос направлен на выявление использования устаревших/несовременных систем контроля версий. Например, при работе с Subversion требуется несколько иной процесс работы с кодом и ветками, который может быть не знаком проектной команде. Так же при использовании SVN сложно применять best practices, описанные ниже в этом документе – организация работы через pull request-ы и т.д.
Где хостится код (локально в компании, “у заказчика” или в общедоступном сервисе), в какой системе (Bitbucket, GitHub, GitLab, etc.)? Есть ли у репозитория “зеркала”?
Вопрос направлен на выявление сложных сценариев работы с кодом, например – “репозиторий у заказчика, у нас локальное зеркало где мы ведем разработку и доставляем потом заказчику”. Такие сценарии требуют повышенного внимания со стороны технического лидера либо наличия нетривиальных знаний работы с VCS у членов команды либо продвинутой автоматизации процесса. Менеджеру, как и другим членам команды, важно понимать детали такого сценария работы. В идеале он должен быть формализован (описан).
Как организован доступ к репозиторию (login/password, ssh ключи, etc.)? У каждого ли разработчика свои “креды”? Кто управляет выдачей и заменой ключей?
Очень важно, чтобы доступ к репозиторию (даже в режиме “только чтение” был персонализирован. Отсутствие shared учетных записей позволяет идентифицировать действия пользователей, получать подробную историю и хронологию действий. Желательно, чтобы доступ из автоматизированных систем к репозиторию исходного кода был организован безопасно (с использованием отдельной пары ssh ключей) и обезличенно (не через учетную запись одного из разработчиков).
Не стоит “делиться” ключами доступа и/или лоном/паролем с коллегами, это противоречит политике использования паролей и может привести к нежелательным инцидентам.
Какая модель branch-инга используется (gitflow, github-flow, trunk-based, etc.)? Перечислите одно или несколько названий “основных” веток.
Хорошей практикой является использование одной из широко известной и описанной модели ветвлений. Если разработчик, отвечая на этот вопрос не приводит ее название – это повод к тому, чтобы закрепить с командой на очередном daily meeting-е этот момент – особенности, именование веток, требования к участникам команды предъявляемые моделью бранчевания и т.д.
Вопрос про названия веток нужен, чтобы выявить неявно используемую “модель” а так же понять существуют ли расхождения со “стандартом” (что чревато “костылями” в процессе работы над изменениями и доставками).
Используют ли pull request-ы для разработки фичей и исправления багов? Обязательно ли их использование или опционально?
Методика разработки через feature branches или pull requests является рекомендованной в компании. Она позволяет организовать максимально независимую работу разработчиков – без необходимости частой синхронизации между ними. Большим плюсом этой методики является простота участия всех членов проектной команды в процессе code review, так как каждая новая feature, исправленный дефект, или доставка версии представлены отдельными ветками в репозитории исходного кода. Желательно, чтобы любое вносимое в ПО изменение происходило через создание отдельной ветки и включение ее (после code review) в основной стрим (обычно, ветка master). Если на проекте используется trunk-based workflow (при котором разработчики работают с одной и той же веткой), то для организация эффективного code review процесса нетривиальна. Отсутствие запрета на прямое внесение изменений (push) в основные ветки разработки (develop, master) приводит к злоупотреблению “hot-fix”-ами для срочного решения проблем и, следовательно, не позволяет выстроить правильную deploy-rollback стратегию.
Удаляются ли feature-ветки после merge-а в основной стрим? Проводится ли поддержка сразу нескольких версий приложения в параллельных ветках?
Обилие веток, которые были смержены в основной стрим может запутать незнакомого с проектом человека, затруднить идентификацию важных веток (при их наличии) от тех, которые уже были влиты с основной стрим. Так что правилом хорошего тона является удаление feature-ветки после ее merge-а (в Bitbucket для этого есть специальная галочка в диалоговом окне merge-а).
Отрицательный ответ на него не критичен, однако может выявить наличие долго-живущих веток, в которых ведется разработка какого-либо большого изменений, что нередко спустя продолжительное время приводит к достаточно сложному процессу слияния в единый стрим.
Обязательно ли исправление замечаний от reviewer-ов? Сбрасываются ли approve-ы после добавления новых комитов в pull request?
Процесс code review направлен не только на улучшение качества кода проекта, но и на развитие коммуникации внутри команды, повышение технического уровня команды разработки. Если в процессе code review один из членов команды высказал замечание либо задал вопрос – он обязательно должен быть рассмотрен. В противном случае мотивация человека задающего вопросы быстро угаснет и польза от такого code review сойдет на нет. Если по какому-либо замечанию в процессе ревью возник спор/дискуссия – стоит убедиться, что команда пришла к единому конечному мнению.
Практика сбрасывать approve-ы после добавления нового комита опциональна, это очень удобно при наличии в команде разработки начинающих разработчиков, когда нет уверенности что комитом с исправлениями замечаний качество кода будут действительно улучшено. В сильных, состоявшихся командах такая практика не требуется, если разработчик уже поставил отметку approve на код, он предполагает, что последующие комиты будут носить косметический характер и не потребуют детального ревью всего pull request-а.
Все ли члены команды могут/участвуют в code review?
Важно, чтобы все разработчики из команды принимали участие в процессе code review. Это важно, так как code review предназначен не только для нахождения проблем в коде, но и для повышения квалификации разработчиков, которые принимают в нем участие, для поддержания общей ответственности за код (чтобы каждый разработчик из команды был знаком со всей кодовой базой, а не только со “своим модулем”), для развития внутри командного общения и повышения культуры разработки. Таким образом – мнение каждого члена команды, вне зависимости от его квалификации должно трактоваться с одинаковой важностью.
Разрешены ли force push-ы в основные ветки, feature-ветки?
Force-push это средство для “переписывания истории”. Его стоит рассматривать в двух контекстах – force push в feature ветки и force push в основные ветки. И если первое – допустимо (происходит в случае, когда разработчик в процессе работы над feature сделал много комитов и/или желает исправить один из них, делает force push в свою ветку, меняя историю комитов на иную), то второе – крайне нежелательно (при force push-е в основную ветку заменяется “история комитов” в основной ветке репозитория, что автоматически делает локальные копии у всех других разработчиков “несовместимыми” с версией кода в репозитории.
Force push бывает весьма полезен, но инструмент это достаточно опасный в неумелых руках. Рекомендуется возможность force push в репозитории отключать, во избежание опасных последствий и, собственно, изменения истории. Разработчики уделяют комментариям к комитам и их атомарности меньше внимания, когда знают, что в последствии можно будет все “подправить”. Само по себе это так и ужасно, однако порождает дополнительные сложности для внимательного review-ера, который решил запустить код в ветке у себя локально. При проведении последующей проверки в этой ветке он обнаружит, что простого git pull уже недостаточно для “подтягивания” последней версии. Так же замена комитов в pull request-е не позволяет понять когда и в какой последовательности разработчик вносил изменения. Предлагается быть честными с самими собой и коллегами и не пользоваться force push для того, чтобы “показаться лучше”.
Практикуется ли линеаризация истории (при помощи rebase или squash) при финальном мерже веток? При работе над feature-веткой?
Линеаризация истории – это такая практика, при которой стараются добиться линейности истории репозитория (как будто веток и не существовало вовсе). Аргументацией для таких действий служит “упрощение” для последующей работы с историей репозитория. Однако линеаризация, по сути, есть “изменение истории”, так как комиты в репозитории больше не отражают фактического порядка их добавления.
Существуют два способа достижения линеаризации: rebase и squash. При rebase-е все комиты в feature ветке, при ее присоединении к основному стриму разработки, помещаются на вершину дерева истории, как будто разработка и велась в основной ветке. При sqash-е перед финальным merge-ем изменений в основную ветку происходит “схлопывание” комитов в один, как будто все работы над feature были сделаны единовременно и сразу правильно (без исправлений в процессе code review).
Доводом против линеаризации служит такой аргумент: из полной истории репозитория всегда можно получить линеаризованную версию (например для передачи заказчику), а из линеаризованной (краткой, сокращенной) версии репозитория восстановить истинную историю уже не получится. Так же при использовании методики линеаризации часто необходимо разрешать force push в репозиторий, что влечет за собой все нюансы последнего.
Настроены ли ограничения на формат commit messages и какие?
Консистентность и подробность commit сообщений – важный аспект культуры разработки. Существуют общепринятые рекомендации и даже стандарты для оформления commit сообщений. Умение составлять качественные commit сообщения – такой же важный skill для разработчика, как и написание качественного кода, его можно и нужно тренировать. Так как на разных проектах могут применяться разные требования и ограничения для commit сообщений, хорошей практикой считается проверка сообщения на соответствие шаблону. Например, commit message в обязательном порядке должен содержать номер задачи в JIRA, над которой работал разработчик в процессе создания этого изменения кода. Менее популярным и более строгим требованием может служить ограничение на минимальную длину комит сообщения (для гарантирования подробности).
Нередко commit сообщения могут служить не только “для исторических скрижалей”, но и для взаимодействия с системой управления задачами, например.
Обязательно ли указание номера задачи в commit сообщении? Как быть если задача “техническая” (рефакторинг, правка опечаток, version bump, другие действия, для которых нет задачи)?
Для достижения большего уровня прозрачности для менеджера и/или заказчика, принято в каждом commit сообщений оставлять номер задачи, над которой трудился разработчик в момент commit-а. Это позволяет и настраивать интеграция JIRA с Bitbucket (или другой системой хостинга репозитория исходного кода) для просмотра “списка комитов по задаче” и легко находить задачу в рамках которой велась работа над интересующей строчкой исходного кода и т.д. Случается, что изменения в исходном коде совершаются не в рамках какой-то задачи (исправление опечатки, обновление версии зависимости и др.). Так как в этом случае указать номер задачи из проектного task tracker-а не представляется возможным, часто прибегают к “обходным маневрам”, указывая несуществующую задачу вида TASK-0 или TASK-X. Важно, чтобы все члены команды знали “что делать” в случае отсутствия задачи – указывать синтетический ID (чтобы удовлетворить ограничения на формат сообщения), создать задачу в трекере и т.д.
Приведите список 6 самых коротких commit сообщений. А так же список top-5 повторяющихся commit сообщений. Как были получены эти списки?
Для ответа на этот вопрос отвечающий должен обладать начальными навыками автоматизации задач, возникающих перед разработчиками каждодневно. Важно, чтобы отвечающий объяснил методику или привел скрипт, при помощи которого он получил ответ. Если для получения ответа понадобилось больше 1 минуты труда разработчика – стоит обратить на это его внимание.
Короткие commit сообщения являются признаком низкой культуры разработки. Желательно из избегать. Любой аудит со стороны заказчика или выполненный независимой стороной выявит обилие коротких и/или повторяющихся commit сообщений и сможет строить суждение о профессионализме разработчиков, их создавших.
Консистентны ли email-ы и username-ы всех контрибьютеров в репозитории?
Разработчики компании, работая с репозиторием исходных кодов должны использовать корпоративные учетные записи, email-ы. Неконсистентность в email-ах и именах пользователей бросается с глаза даже при поверхностном аудите репозитория с исходным кодом и также свидетельствует о низком уровне контроля процессов разработки на проекте. Также нередко можно встретить ситуацию, когда один и тот же разработчик использует разные настройки git-а для работы с репозиторием с разных устройств. Для предотвращения возможных замечаний и неудобных вопросов “а кто такой ‘$uPeRmEgA/usr@protonmail.com’ и почему он делает комиты в наш репозиторий” со стороны заказчика предлагается настраивать ограничения на возможные email-ы и username-ы в репозитории. При наличии legacy разночтений – их возможно устранить при помощи force push.
Используются ли локальные и/или серверные hook-и для commit-ов (если да, то какие)?
Для повышения качества и атомарности комитов можно использовать commit hook-и. С их помощью можно организовывать локальные или серверные проверки разного рода. К примеру – не забыл ли разработчик перед commit-ом удалить debug вывод, правильно ли оформлено само commit сообщение и т.д. Существуют целые framework-и для управления commit hook-ами, которые позволяют удобным образом настраивать их для репозитория.
Настроена ли интеграция code review процесса с CI (можно ли вмержить pull request без зеленого билда)?
Интеграция CI с процессом разработки через pull request-ы очень удобна, Bitbucket помечает ветки (и комиты) по которым CI собрал билд как зеленые либо красные. Рекомендуется настроить требование – запрет merge-а pull request-а, если сборка не была успешной. Настроенный таким образом процесс защищает от случайного внесения ошибок и/или непротестированного кода в основную ветку.
Есть ли в репозитории понятный и исчерпывающий readme файл? Когда в последний раз он обновлялся?
При добавлении нового разработчика в проектную команду, у него неизбежно возникает множество вопросов о том, как запустить, как настроить рабочее окружение, где взять реквизиты доступа и т.д. Readme файл в корне репозитория исходных текстов – отличное место для хранения подобной информации. Проверкой качества Readme файла является количество вопросов от незнакомого с проектом человека, который пытается “запустить” и “настроить” все локально. Хороший Readme файл не содержит паролей, токенов и другой чувствительной информации (даже о staging окружении).
Ведется ли список исключений (ignore) из репозитория, включены ли в него файлы с специфичными для окружения настройками, артефакты пакетных менеджеров (например, build, libs, node_modules, etc.)?
Чтобы избежать попадания в репозиторий исходных текстов чувствительной информации (пароли, токены и др.), принято отделять конфигурационные файлы, в которых такая информация содержится. Такие файлы помечаются как “игнорируемые” системой контроля вервий, чтобы при ежедневном внесении изменений в такие файлы – изменения случайно не были помещены в репозиторий. Так же принято не хранить артефакты сборки (скомпилированные или иным образом собранные, сгенерированные файлы), исходные тексты внешних зависимостей в репозитории – это увеличивает размер репозитория и затрудняет работу с ним.
Практикуется ли использование LFS для хранения больших и/или бинарных файлов?
Если по какой-то причине хранить большие бинарные файлы в репозитории все же приходится, лучше использовать для этих целей LFS. При использовании LFS большие бинарные файлы хранятся физически вне репозитория, типичные команды по работе с репозиторием не занимают больше времени, чем обычно.
Если в проекте есть сторонние бинарные зависимости, где они хранятся (в репозитории, в локальном nuget, в облачном artifactory, etc.)?
Часто в legacy проектах имеются бинарные зависимости (утерян или отсутствует исходный код). Так же при сборке частей проекта такие внутренние зависимости образуются. Если хранение первых в репозитории может являться допустимым (при использовании LFS), то хранить вторые в репозитории точно не стоит. Результаты сборок (билды) лучше хранить в специально предназначенной для этого системе (роль которой, до некоторой степени, может играть CI). Использование специализированной системы для хранения сборок (docker registry, artifactory, nuget, etc.) позволяет трактовать внутренние зависимости таким же образом, как и внешние – версионировать, кешировать, и т.д.
При помощи какого инструмента(ов) ведется управление зависимостями и их версиями (maven, yarn, gradle, rubygems, npm, docker, etc.)?
Управление зависимостями – неотъемлемая часть процесса работы над программным продуктом. Важными аспектами, помимо версионирования как такового, процесса управления зависимостями являются: фиксация версий, обеспечение воспроизводимости, вендоринг, периодичность обновления зависимостей, отслеживание уязвимостей, управление лицензиями и обеспечение достоверности (fingerprinting). Инструмент, при помощи которого ведется работа с зависимостями определяет набор возможностей, гибкость и удобство работы как с внешними, так и с внутренними (при многомодульной структуре) зависимостями проекта. Члены проектной команды должны понимать возможности и ограничения используемого инструмента, уметь эффективно его использовать.
Приведите пример двух pull request-ов, которые находились в review долгое время и опишите причины.
Существует множество причин, по которым pull request может долгое время находится в состоянии code review, однако не все причины одинаковым образом свидетельствуют о здоровье (или нездоровье) SDLC процессов на проекте. Важно выявлять ситуации, когда члены проектной команды, находя оправдания в неактивности коллег, задерживают закрытие задачи оставляя ее в статусе code review. Важно помнить, что доведение задачи до завершения – всецело находится в сфере ответственности ее исполнителя. Нежелание коллег вовремя обращать внимание на входящие pull request-ы ожидающие review может и должно быть преодолено силами проектного менеджера, технического лидера и команды в целом.
Оцените (приблизительно) среднее количество комментариев per pull request в последнее время (0-1, 1-5, 5-20, 20-50, 50+, etc.).
Крайне низкий показатель часто свидетельствует не о высоком качестве исходного кода, а о непонимании роли code review в процессе разработки ПО. Code review нужен не только для обеспечения единообразия и качества кода, но и для обучения членов проектной команды, распределении ответственности за код между разработчиками, повышению soft skill-ов. Стабильно большое количество комментариев может служить свидетельством дисбаланса проектной команды (слишком большой разрыв в уровнях квалификаций разработчиков).
Приведите список (email, username) всех контрибьютеров проекта в порядке уменьшения количества комитов за последний год.
Возможность создания подобного списка доступна практически каждому разработчику и не занимает много времени на подготовку. Такой отчет позволит удостовериться, в консистентности используемых адресов электронной почты, формате username-ов, наличию комитов от заказчика и т.д. Информация не будет использована для оценки “вклада” в проект и/или суждений о продуктивности отдельных разработчиков.
Использование данного отчета может позволить ответить на несколько других вопросов из данного отчета.
Содержат ли какие-то из закомиченых файлов пароли/токены/креды к любому из окружений/серверов/сервисов?
Хранение паролей/токенов любого характера и толка в репозитории – плохая и опасная практика. Несмотря даже на то, что это информация может относиться к изолированному staging или даже локальному окружению. Даже если они “потом будут встроены в итоговый html”. Даже если пароль “явно выглядит как заглушка”. Наличие паролей “от staging-а” может легко привести к компрометации настроек “от prod-а”, лучше вообще не показывать такой пример. Вместо этого – хранить настройки окружения на самом окружении (сервере в рамках внутренних переменных или настроек сессии) и/или недоступном для основной проектной команды месте (CI, Wiki, password manager, etc.) Отличной стратегией является хранение названий конфигурационных ключей в .env.example файле в репозитории, но без каких либо значений. Приложение при старте может/должно проверять целостность и полноту конфигурации (значения ключей) и “падать” при обнаружении проблем.
- CI
Используется ли CI на проекте и какой (TeamCity, Jenkins, GitHub Actions, GitLab pipelines, etc.)?
На проектах любого размера, рекомендуемой практикой является использование Continuous Integration практики. CI позволяет удостоверится в том, что внесенные изменения не привели к поломке продукта (не отломали unit и integration тесты), запустить статический анализ. кода, автоматизировать другие рутинные проверки. Отсутствие CI говорит о незрелости процессов разработки, отсутствию повышенного внимания к качеству выполняемых работ, провоцирует использование ручного труда для выполнения рутинных, легко автоматизируемых действий.
Какие задачи выполняет CI сервер (lint-инг, компиляция, запуск unit тестов, запуск интеграционных тестов, статический анализ, доставка)?
CI может (и должен) выступать не только как инструмент сборки запуска тестов, но и как центр автоматизации всех остальных рутинных задач. Все повторяющиеся операции, которые проектная команда вынуждены выполнять как минимум несколько раз в неделю подлежат автоматизации и помещению на CI. Работы по настройке CI обязательно выполнять на старте проекта, эти усилия окупятся сторицей – CI сильно экономит время.
Все ли члены проектной команды (в том числе менеджеры и QA) имеют доступ к CI?
Наличие доступа к CI сервису позволяет организовать порядок выполнения повторяющихся автоматизированных процессов, а также обеспечить информированность об их состоянии. Часто подобное использование сервиса является способом взаимодействия между отдельными частями команды (Dev, QA, DevOPS, etc.), тем самым вводя дополнительные факторы ранней проверки зрелости процессов. Также, доступ для нескольких участников позволяет защититься от простоя в случае непредвиденных обстоятельств с кем-то одним.
Используется корпоративная учетная запись (корпоративная или заказчика) для доступа к CI? Существуют ли на CI учетные записи людей, уже покинувших проект? Доступна ли - функция регистрации и сброса пароля на CI?
Через сервис CI зачастую содержит организованно управление проектными ресурсами, версиями, состоянием приложений, а также автоматизированными процессами через отдельный уровень доступа с повышенными привилегиями. Обеспечение учета и контроля способа доступа к CI позволяет снизить шанс случайных или злонамеренных действий третьих лиц. Параллельно с контролем доступа к остальным ресурсам проекта (репозиторий кода, проектная wiki, jira, etc.) необходимо также отражать любые изменения и в подсистеме CI.
Функция регистрации и сброса пароля на CI зачастую является включенной “по-умолчанию” при установке из стандартных пакетов CI сервиса, но при этом разрешают регистрацию новых пользователей без подтверждения от администратора системы, и получения пароля при компрометации почты существующего пользователя.
Предоставьте несколько отчетов об успешной (и неуспешной) сборке с CI (отчет о прохождении тестов, отчет статического анализатора, дерево зависимостей build plan-ов).
Наличие или отсутствие подобных отчетов позволяет определить зрелость процессов разработки в проекте, а так выявить узкие места, которые потенциально стоит улучшить в организации ведения кода и зависимостей, сборки, тестирования и доставки на окружения. Содержание отчетов не обязательно должно быть “чистым” (подойдут html страницы или даже screenshot-ы с отчетами по успешным и неуспешным сборкам). Основным фактором является возможность их предоставления – само их наличие.
Падает ли билд при наличии проблем с форматированием исходного кода, упавшими тестами?
Один из успешных способов поддержания единообразия стилизации, подхода к написанию, и соблюдения практик применяемых для раннего обнаружения ошибок – это включение механизмов статической проверки кода (исходя из предустановленных правил) и выполнение автоматических тестов во время сборки частей или всего проекта. Стоит учесть, что в зависимости от проекта сборка может происходить как на CI сервере, так и на локальных машинах, но чем раньше разработчики столкнутся с “падением” (ошибкой) сборки при доставке своих изменений в систему, тем проще вносить необходимые правки.
Падение при сборке не всегда может приводить к остановке всего процесса доставки, а зачастую является предупреждением о необходимости дополнительных действий. Правда с таким подходом следует быть аккуратными и применять только там где шанс ущерба системе при очередной доставке минимален.
Отслеживается ли покрытие кода тестами на CI и может ли недостаточный уровень покрытия привести к красному билду?
Использование методики анализа эффективности и достаточности автоматических тестов (в дополнение к их номинальному наличию в системе) позволяет более точно оценить реальное покрытие функциональных частей кода, а также оперативно выявлять в нем важные пограничные ситуации. Наличие или отсутствие методик по сбору статистики покрытия, а также блокировка прохождения сборки при недостаточном уровне свидетельствует об уровне внимания команды к создаваемому коду, в том числе и в виде дополнительных самопроверок.
Анализируется ли lint-ером только добавленный код или весь код проекта?
Нередко можно встретить такую отговорку против использования статических анализаторов и/или lint-еров: “в этом проекте много legacy кода, мы не можем себе позволить его переписать/отрефакторить”. Однако даже на проектах с нетривиальной историей существуют эффективные стратегии по приведению кода “в порядок” и поддержанию заданного уровня качества для добавляемого нового кода. Достаточно настроить средства статического анализа (возможно, оборачивая их дополнительными скриптами) таким образом, чтобы из их отчетов вырезались замечания только по строкам, которые были изменены в рамках pull request-а. Эта стратегия, с одной стороны, не вызывает у членов команды разработки отторжения (не требуется исправлять чужой код, только тот, который был затронут изменением) а с другой, со временем, приводит кодовую базу к принятым стандартам.
Дополнительной стратегией может служить правило – если в процессе работы над pull request-ом какой-либо файл был изменен более чем на половину (подсчет можно сделать либо по diff-у, либо другим способом, эвристикой) – он объявляется “не legacy” и подлежит полной проверке (принятыми на проекте linter-ами, договоренностями о минимальном покрытии тестами и т.д.). Со временем, метрика может измениться – вместо половины файла отслеживать изменился ли он на треть.
Производится ли сборка на CI по каждому комиту либо кумулятивно?
Выполнение сборки для отдельных веток (содержащие изменения еще не доставленные в основной “поток”), является полезным для автоматизированной проверки соответствия произведенных изменений существующим практикам и правилам. В зависимости от размера проекта (количество подпроектов или модулей) и объема кодовой базы, сборка может занимать достаточно продолжительное время и ее невозможно/не эффективно выполнять на каждое отдельное изменение. Для таких случаев подходит кумулятивная сборка из отдельных веток, а также только в случае подачи запроса на “слияние” в основные ветки.
Доступен ли CI сервер из интернета? Если да, то настроены ли ограничения по IP?
В рамках CI сервера практически всегда находятся: ключи для доступа к репозиторию проекта (часто с отдельным супер-пользователем), копия кода проекта, конфигурация доступа к окружения для его сборки и развертывания, а также персональные почтовые адреса для рассылки уведомлений. Несанкционированный доступ к CI серверу может привести достаточно к серьезным проблемам безопасности и нарушению политик работы с персональными данными. Защита на инфраструктурном уровне является ключевым подходом для физического и географического ограничения круга доверенных лиц.
Опишите как происходит работа с secure данными на CI (пароли, токены, подписи dll, etc.).
Современные CI системы (например TeamCity) умеют работать с чувствительными данными: хранят в зашифрованном виде и не позволяют получить доступ к уже сохраненным значениям через GUI и API, прячут из логов сборки вычищая по имени и/или значению, разграничивают доступ к изменению чувствительных данных в зависимости от привилегий пользователя и т.д.
- Communication
Перечислите всех разработчиков проекта с их ролями (не формально, а de facto).
Необходимо для:
- заполнения информации в проектной карте (для того чтобы у тимлидов, архитектора и др. появился доступ на редактирование);
- выявления ситуаций, когда разработчик фактически занимается активностями лидера проекта, но его тим(тех)лидом официально не признали;
- выявления “лишних” разработчиков, все еще состоящих в проектной группе, но фактически в проект не вовлеченных;
- понимания количества вовлеченных к процессы коммуникации разработчиков.
Есть ли в проектной команде откровенно слабые разработчики, супер-технари, на которых хочется ровняться? Кто, если не секрет?
Необходимо для:
- выявления ситуации, когда на поддержку начинающего разработчика тратится неоправданно много усилий проектной команды либо человека с неподходящей для этого квалификацией (его время может быть для проекта очень ценно, менторинг можно отдать другому специалисту);
- выявления “непризнанных лидеров”, про которых незаслуженно забыли или не совсем верно оценили их квалификацию, поощрение людей, которые заслуживают от коллег отзывов “супер-технарь” – важно;
- определения возможных перекосов в квалификации команды, иногда баланс, в моменте, не достигается. Важно, чтобы у менеджера был четкий план по выравниванию среднего уровня проектной команды.
Существует ли проектная группа рассылки? Все ли члены группы вовлечены в разработку (нет ли “лишних”)?
Исходя из того, что доступ к проектным окружениям и ресурсам выдается не персонально, а “по группам”, членство в проектной группе обеспечивает не только получение писем касательно проектных активностей, но и возможность авторизовываться в инфраструктурных сервисах, иметь доступ к репозиторию с исходными текстами, документации проекта. Нередко наблюдается ситуация, при которой в проектной группе фактически состоит большее количество людей, чем реально вовлечено в разработку. Так случается по историческим причинам, в связи с ротацией и “текучкой”. Для менеджера проекта важно следить (а для всех остальных членов проекта - напоминать ему) за составом проектных групп (их может быть несколько), вовремя исключать из нее разработчиков, покидающих проект, своевременно добавлять в нее новых членов проектной команды.
С технической стороны очень важно обеспечивать доступ ко всем инфраструтурным системам и сервисам именно по группе, а не индивидуально. Таким образом, у покидающего проект разработчика автоматическим пропадет доступ и требования безопасности ISO 27001 будут соблюдены.
Используется ли проектная группа для коммуникации с заказчиком?
Проектная группа автоматически является еще и группой рассылки почтовых сообщений. Ее удобно использовать, чтобы сообщение в почте было гарантировано доставлено всем участникам проекта. Такой почтовый адрес удобно ставить к копию писем для заказчика, чтобы ответ тоже пришел всем. Однако с такой практикой может быть связана определенная опасность: некоторые почтовые клиенты “любят” разыменовывать группу, подставляя вместо нее индивидуальных участников группы. Если на проекте есть люди, не представленные клиенту - лучше не использовать проектную группы рассылки я письмах заказчика и/или иметь несколько почтовых групп.
Может ли менеджер и/или технический лидер/технический координатор менять состав проектной группы? Знают ли они как это сделать без HD?
Изменение состава проектных групп можно провести самостоятельно, не прибегая к помощи инженеров поддержки из HelpDesk-а. Это ускоряет/упрощает процесс управления проектными группами - проектный менеджер может назначить (со-)владельцем проектной группы технического координатора и/или технического лидера тем самым делегируя ему ответственность за поддержание состава проектной группы в консистентном состоянии.
Существует ли в письменном виде onboarding guide для новых членов проектной команды (ссылки на документацию, настройка локального окружения, необходимые зависимости и - их версии)?
Для то го, чтобы новый член команды разработки не отвлекал опытных разработчиков вопросами “а как настроить” и “а где находится”, на проекте должен существовать onboarding guide. Формат и расположение документа особого значения не имеет, однако рекомендуется его хранить в репозитории исходный кодов в виде README документа на английском языке. Таким образом, новый разработчик (в том числе и внешний, со стороны заказчика) сразу после клонирования репозитория получает исчерпывающие инструкции по развертыванию и настройке локального окружения разработки.
Есть есть необходимость, возможно автоматизировать настройку окружения, создав набор скриптов для initial clone и gradual update сценариев.
Есть ли у команды разработки проектный чат? Добавлен ли туда менеджер? Какие еще средства коммуникации используются для ежедневного общения?
“Чат проекта”, “чат комнаты”, “чат команды бэкэнда”, знакомо? А вот такие сообщения в ваших проектных чатах бывают “бэкэнд команда надоела, сколько можно менять API” или “что этот менеджер от нас хочет со своими оценками, не понятно же ничего”? Такие “выкрики в пустоту” отличный способ психологической разрядки, но построить слаженную командную работу, если в чате frontend-а нет бэкэндеров или в чате разработчиков нет менеджера - не выйдет. Если есть проблема, менеджер проекта должен о ней знать, иначе у него просто не будет возможности повлиять на ситуацию и исключить появление проблемы в будущем. Пожалуйста, убедитесь что: все члены проектной команды находятся в общем чате; все возникающие проблемы обсуждаются и не игнорируются (ни членами команды разработки, ни менеджером).
В какие системы разработчик получает доступ, когда его добавляют в проектную группу?
В идеале - разработчик должен получать доступ ко всем проектным и инфраструктурным системам (доступным любому другому разработчику проекта) после добавления в проектную группу. Если это не так - возможно стоит пересмотреть способ авторизации в систему, где такое правило не выполняется (например проектный CI, где доступ осуществляется по персональным учетным записям).
Все ли члены проектной группы знают кто является менеджером проекта, техническим координатором проекта?
Да, бывает так, что “не знают”… Ознакомиться с ключевыми персоналиями проекта можно взглянув на проектную карту, которую всегда можно найти на вкладке “Project Card Info” вашего Jira проекта. Доступ “на чтение” к проектной карте есть у всех людей, которые входят в какую-либо группу рассылки, относящуюся к проекте. Доступ на редактирование проектной карты есть у любого, кто “упоминается” в проектной карте (техлид, архитектор, менеджер и т.д.).
Как часто проводятся ретроспективы, планируются и выполняются ли принятые на них решения?
Проводить ретроспективы и записывать принятые командой договоренности - это только первый шаг к тому, чтобы действительно следовать Agile методологии разработки. Задача проектной команды - стремиться к выполнению достигнутых договоренностей. Отслеживаются ли на проекте (в рамках ретроспектив или же вне их) сроки и результат выполнения задач, сформулированных на ретроспектиных встречах? В каком виде эти задачи вообще формулируются (страница на Wiki, задачи в Jira, etc.)?
Есть ли на проекте junior разработчики, за которыми требуется “присмотр”? Кто его осуществляет и как?
Система квалификаций разработчиков четко определяет навык, который отличает начинающего (junoir) разработчика - способность к самостоятельной работе без необходимости иметь пошаговые инструкции. Так за junior разработчиками нужен обязательный присмотр. Осуществляться он должен в проверке всех результатов их работы. Никакой код, документация или другие артефакты, созданные junior разработчиком не должны оказаться “не просмотренными”. А еще лучше - осуществлять контроль и оказывать необходимую помощь в процессе написания кода и создания других артефактов (часто таким образом можно избежать ненужных трат времени).
Для разработчиков хорошим способом осуществления контроля является своевременный код ревью с подробными комментариями. Очень желательно, чтобы комментарии существовали в письменном виде. Менторство - процесс двунаправленный, происходит обучение не только junior-а, но и mentor-а (способности полно и понятно выражать замечания, проводить аудит кода и т.д.)
Могут ли разработчики создавать новые задачи в task tracking системе для “улучшений”? Каким образом ведется отслеживание и работа над “техническим долгом”?
Документ с “хотелками” на wiki, куда ведется только добавление новых пунктов - нельзя назвать полноценной работой с техническим долгом. Как и массу TODO комментариев в исходном коде. Если что-то должно быть сделано (и команда с этим согласна) - необходимо такую работу планировать, приоритизировать как любую другую - следовательно иметь ее в виде зарегистрированной задачи в tracking системе (в роли которой чаще всего выступает JIRA). Откажитесь от TODO в коде (хотя-бы проведите исследование на тему “сколько там всего накопилось”) в пользу регистрации задач в JIRA для “улучшений” и “доделок”, пропагандируйте в процессе code review создание таких задач, если автор кода, в ответ на замечание, отвечает “доделаем потом” или код содержит комментарий TODO в явном виде.
Работают ли на проекте люди, о которых заказчик “не знает”? Как организован их доступ к коду проекта?
Иногда возникает необходимость “потренировать” разработчика на проекте до официального представления заказчику. Причин может быть несколько - высокие ожидания заказчика к уровню квалификации разработчиков в команде, наличие специфичных технологий на проекте с которыми требуется предварительное ознакомление, наличие стороннего (не входящего в проектную команду) аудитора, осуществляющего контроль за разработкой и т.д.
Важно помнить, что требования DNA обязывают не распространять артефакты интеллектуальной собственности третьим лицам, то есть - не высылать по почте или на сменных носителях или выкладывать в места общего доступа проектную документацию, исходный код проекта и т.д.
Для целей code review в рамках пересмотра квалификации не нужно высылать архив проекта, достаточно будет 10-15 последних коммитов в виде git patch файлов (с авторством, датой и commit message-ем). Предоставление такого ограниченного объема исходного кода аудитору (техническому координатору, члену квалификационной комиссии) не может трактоваться как нарушение NDA.
Практикуется ли работа с кодом “из дома”, на каком оборудовании (личном, заказчика, принадлежащем компании)?
Одной из обязанностей компании перед ее заказчиками является защита интеллектуальной собственности. В этих целях осуществляется шифрование носителей корпоративных ноутбуков (защита на случай потери или кражи, такие случаи не редки), централизованное управление учетными записями, аудит и контроль доступа к корпоративным ресурсам и др. Компания старается найти баланс между обеспечением должного уровня безопасности и удобством сотрудников, о чем свидетельствует BYOD политика и доступность репозиториев с кодом без VPN. Однако к устройствам, принадлежащим сотрудникам предъявляется рад требований (членство в домене, шифрование, антивирус и т.д.) Если члены команды работают на личном оборудовании, о котором компания “не знает”, это автоматический означает что компания не в полном мере исполняет свои обязательства перед заказчиком по защите его интеллектуальной собственности.
Вспомните, клонировали ли вы исходный код проекта на “домашний комп”, остался ли он там? Ноутбук, за которым вы работаете зарегистрирован в MDIS и приведен в соответствие корпоративным стандартам? Оборудованием, за которым вы осуществляете работу с исходниками, пользуется ли кто-то еще? Сколько публичных ключей добавлено в ваш профиль на BitBucket-е (используете ли вы авторизацию по ключу или по доменному паролю)?
- Deploy
Как организована доставка кода на различные проектные окружения (dev, staging, production, etc.)? Автоматизирована ли она и в какой мере?
Ключ к сокращению time-to-market показателя – в автоматизации. Команда разработки должна иметь возможность доставлять сборки без промедлений и препятствий. Автоматизация процесса доставки позволяет исключить (или, по крайней мере, сильно сократить) влияние “человеческого фактора”. А раз он исключен – доставкой могут заниматься большее количество людей, без необходимости понимать детали. Автоматизированный процесс доставки позволяет уйти от получения версий только через регулярные продолжительные интервалы времени (например, в рамках “двухнедельных спринтов”) и доставлять изменения на различные окружения хоть несколько раз в день, с возможностью откатиться на предыдущую версию при необходимости.
Важными аспектами автоматизации доставки являются: скорость (как долго происходит доставка), бесшовность (наличие maintenance окна при доставке, в течение которого система недоступна пользователям), идемпотентность (возможно ли “доставить” один и тот же билд несколько раз подряд и ничего не сломать).
Могут ли QA самостоятельно “поставить себе билд” используя CI и/или средства контейнеризации (docker, docker-compose, kubctl, etc.)?
Раз уж доставка автоматизирована – нет причин отвлекать разработчиков доставками билдов для тестирования. Необходимо дать инженерам по качеству самостоятельно собирать и доставлять на свои окружения сборки для тестирования. Эта возможность особенно ценна, если QA окружений несколько. В этом случае тестирование каждой feature может происходить параллельно – нет необходимости “собирать единый билд для QA”, QA инженер сам/сама может собрать для себя билд из интересующей еговетки и заняться тестированием.
Есть ли у всех членов проектной команды (разработчиков) доступ к тестовым и (pre-)production окружениям? Если нет, то кто именно занимается доставкой?
С одной стороны – весьма полезно каждому разработчику иметь доступ к окружениям для исследования проблем и причин возникновения дефектов. С другой – доступ к production окружению, где содержаться чувствительные данные пользователей и настройки – нежелателен по соображениям безопасности. В соответствиями с требованиями безопасности, предъявляемыми заказчиками, принято разделять группы лиц имеющим и не имеющим доступ к production (и другим важным) окружениям. Порой в составе команды разработчиков людей с доступом “к проду” может и не быть вовсе. В этом случае необходимо иметь способ (системы мониторинга, логгирование) или процесс (коммуникация с командой эксплуатации заказчика) выяснения деталей происходящего на “боевом” окружении.
Используется ли автоматизация для provision-инга нового окружения? Вносятся ли изменения в уже существующую инфраструктуру таким же образом?
Если проект большой (или древний) – вероятно на нем нередко возникает необходимость в настройке нового окружения. Во избежание траты времени на развертывание и настройку этого окружения, целесообразно автоматизировать большую часть процесса. Однако, автоматизация развертывания применяется не только на проектах, где возникновение новых окружений – рядовое событие. Infrastructure as a code парадигма диктует даже первоначальную настройку окружения проводить так, чтобы процесс оказался на выходе “заскриптован” и мог бы использоваться с минимальными затратами времени человека. Дублирование в автоматизированных сценариях любых проведенных вручную изменений инфраструктуры или же выполнение изменений сразу в скриптах с последующим их применением позволяют всегда иметь актуальную версию сценариев для подготовки нового окружения (в случае необходимости создание подобного), а также контролировать качество подготовки и надежность таких изменений.
Опишите как производится rollback билда на предыдущий. Где хранятся артефакты сборки (архив билда, контейнеры, конфигурация)?
Часто можно встретиться с ситуацией, когда разворачивание нового билда на окружении полностью и/или частично автоматизировано, а процедура отката – нет. Более того, никто и никогда такого не делал, как сделать это правильно не знает. В результате – полная поломка или возникшие серьезные проблемы с только что доставленным билдом стопорят команду, так как процедура отката не отработана и не обкатана. Это же наблюдение справедливо и для резервных копий – если делаются резервные копии – то их “восстанавливаемость” должна периодически проверяться, иначе в случае реальной необходимости ими воспользоваться может быть больно…
Для оптимизации (по скорости) процедуры отката – желательно чтобы артефакты сборки проекта (docker образы, бинарные файлы, etc.) по каждой доставляемой версии где-то хранились некоторое время. Можно, конечно, не хранить, но тогда процедура отката будет вынужденно включать в себя сборку проекта, что может занимать значительное время.
Отдельно стоит упомянуть конфигурацию. Если процедура доставки не полностью автоматизирована (в плане доставки изменений конфигурационных значений), то стоит хранить резервные копии конфигурации некоторое время. Ведь вероятность того, что нужно будет отказывать билд не нулевая, а файлы с конфигурацией уже затерли…
Где хранятся пароли, ключи доступа к production серверам и сервисам?
Не у всех членов проектной команды может/должен быть доступ к боевому окружению. Следовательно необходимо ограничивать/разделять доступ к месту, где паролидоступа хранятся. Выбор конкретного доступа не важен, важно наличие ограничений доступа, безопасность метода хранения (и доступа), публичная недоступность и т.д.
Характерны такие точки зрения – “у нас все разработчики имеют доступ к проду, давайте будем хранить ключи прямо в git-е” и “мы работаем на Android приложением, ключи все равно попадут в сборку приложения, давайте будем хранить ключи прямо в git-е”. Они ошибочны сразу по нескольким причинам:
- так разработчики начинают считать, что такая практика “нормальна” и будут осознанно или случайно делать также на проектах, где подобное недопустимо;
- со временем в проекте неизбежно возникает необходимость хранить креды, которые уже нельзя показывать всем разработчикам, и возникает два метода хранения конфигурации;
- любой сторонний аудитор в обязательном порядке выявит этот недостаток и укажет его как свидетельство низкого уровня культурыразработки команды.
- Как сделать лучше – например “женить” код приложения с конфигурационным значениями на этапе сборки на CI сервере. Современные сервера позволяют безопасным образом хранить пароли/токены и другие чувствительные данные и удобно использовать их при сборке, даже не показывая в логах и не предоставляя доступ к их просмотру и/или изменению для неавторизованных для этого членов проекта.