Как убедиться, что вы можете воспроизвести свою кодовую базу и набор инструментов и не обжечься недостающими зависимостями.
Вот некоторые рекомендации, которые я усвоил за последние 40 лет в программном бизнесе. Последние 18 лет своей карьеры я в основном занимался релиз-инжинирингом — брал код у разработчиков и запускал его в производство.
Управление кодом
- Всегда документируйте фактический URL-адрес источника и любую другую информацию, необходимую для доступа к исходному коду или двоичным файлам. Включайте учетные данные или расположение учетных данных (например, см. KeePass).
Зачем ? Вам захочется работать над другими проектами, а не вечно быть поставщиком информации. - Создайте архив tar или zip и сохраните его в резервной копии или архиве, например, Nexus.
Почему? Это документирует именно то, что было извлечено из источник. - Есть ли у вас копия лицензии и версия программного обеспечения или инструмента? Если нет, сделайте это!
Почему? Избегайте судебных исков и упростите процесс аудита своей компании для себя и других. Это показывает, что вы организованы и заботитесь об отслеживании интеллектуальной собственности, чтобы снизить судебные риски. - Скопируйте все файлы в локальный репозиторий. НЕ выполняйте сборку напрямую из удаленного архива, не принадлежащего компании.
Почему? Это защищает компанию от удаления удаленных репозиториев, их недоступности или удаления важных файлов. - Храните всю документацию, исходный код, код сборки и тестовый код вместе. Или, если он «разрознен», включите перекрестные ссылки во всех местах, чтобы можно было найти все связанные части. – начиная не более чем с любой точки. Задокументируйте весь процесс в целом И задокументируйте ДЕТАЛИ (точные пути, имена серверов и т. д.) для исправления и других проблем.
Почему? «Очевидные» вещи могут не быть очевидными спустя месяцы. .
Создание продукта
- Сборки на личном ноутбуке или сервере подходят только для начальной разработки. Но для производства сборки ДОЛЖНЫ выполняться на общем сервере сборки, чтобы можно было отслеживать ВСЕ зависимости и чтобы другие могли быстро это сделать. сборки с минимальным временем настройки.
Почему? Сделайте это, чтобы у вас были согласованные и отслеживаемые сборки. Кроме того, это уменьшает несовместимости и время, необходимое для того, чтобы новые инженеры были в курсе. - Если ваша персональная платформа разработки не имеет таких же версий программного обеспечения или представляет собой ОС, полностью отличающуюся от целевой платформы, кроссплатформенная разработка ДОЛЖНА БЫТЬ регулярно ПРОВЕРЕНА, чтобы убедиться, что сгенерированный код будет работать в production.
Почему? Чтобы не создавать ненужных зависимостей. Примечание. Производственные сборки по-прежнему необходимо выполнять на проверенном общем сервере сборки. - Скопируйте все файлы в локальный репозиторий. НЕ выполняйте сборку напрямую из удаленного внешнего архива, не принадлежащего компании.
Почему? Это защитит вас от удаления удаленного репозитория, его недоступности или удаления файлов.
* Например, npm должен быть «кэширован» и версионирован, а сборки должны выполняться для кешированной версии. (т. е. без прямого NPM) - Не следует использовать внешний код Javascript и изображения. Скопируйте код, который вы хотите использовать, и создайте его версию.
Почему? Что делать, если внешний сайт исчезнет? Что делать, если код javascript изменен и имеет дефект безопасности?
* Исключение: пиксельные изображения, используемые для отслеживания, допустимы. - Храните вместе всю документацию, исходный код, код сборки и код тестирования. Или, если она «разбросана», включите перекрестные ссылки во всех местах. Задокументируйте весь процесс в целом, а также задокументируйте ПОДРОБНОСТИ об исправлениях и других проблемах.
Почему? Чтобы можно было найти все связанные части, начиная практически с любой точки. - Требование внесения изменений только потому, что использовались более новые версии, не является веской причиной. Вот почему старые версии сохраняются и используются.
Почему? Затраты в время и ресурсы будут увеличиваться по мере приближения к производству. Новая версия может добавить к общей стоимости, когда гораздо дешевле упростить вещи на более раннем этапе разработки.
* Слишком часто я видел, как инженеры экономили время и просто перекладывали время и затраты на другую группу. , которые должны выяснить, как сделать код надежным и пригодным для развертывания.
* Есть ли функциональная потребность в более новой версии и нет разумного обходного пути? Это может быть уважительной причиной.
* Если добавляются новые инструменты или сервисы, но есть эквивалентные инструменты в производственной среде, то изменение должно быть обосновано. Например, если нам нужно перейти с Apache на Nginx, есть ли для этого техническая причина? Если вы просто не хотите изучать или использовать Apache, это неприемлемая причина.
* Если требуется производственное изменение, об этом следует как можно скорее сообщить архитекторам производства, чтобы изменение можно было запланировать для всех. QA, промежуточных и рабочих серверов. - Запишите все зависимости и то, что необходимо для настройки среды сборки. Еще лучше запишите сценарий установки с помощью инструментов развертывания и настройки инфраструктуры, таких как Terraform или CFEngine.
Почему ? Сохранить все необходимое в цепочке инструментов. Если вам нужна конкретная ОС, вам лучше иметь установочные диски, файлы ISO или зеркало репо и т. д. - Постарайтесь свести к минимуму изменения внешнего исходного кода (в ваших сборках). Создайте файлы переопределения или локальные файлы конфигурации, чтобы при обновлении версий было легко определить, где потребуются слияния. Например, помещать 1000 файлов библиотек в репозиторий версий, когда изменены только 2 файла, расточительно и «скрывает» местонахождение важных изменений.
Почему? Обновления, вероятно, будут быстрее и надежнее. - Не размещайте версии встроенных файлов в том же репозитории, что и исходный код. Поместите скомпилированные (или сгенерированные) файлы в другое хранилище или место, которое может обрабатывать большие двоичные файлы.
Почему? Репозитории с исходным кодом — худшее место для архивирования встроенных файлов, которые обычно являются двоичными. так что всего одно битовое изменение приведет к тому, что весь файл будет добавлен в репозиторий без «добавочного» сохранения. Также все предыдущие версии останутся в репо «навсегда». - Если это программное обеспечение с открытым исходным кодом по лицензии GNU, и в исходные файлы вносятся изменения для устранения проблем или улучшения кода, то эти изменения следует отправить обратно в исходный репозиторий. >И все изменения ДОЛЖНЫ быть общедоступными.
Почему? Это «стоимость» использования открытого исходного кода. - Следуйте шаблону сборки, который используется во всех основных продуктах.
Почему? Вы можете использовать другие сборки и сократить время, необходимое другим, чтобы понять, как выполнять сборки и развертывания. Не создавайте свой собственный процесс, если только вы не получите одобрение от Release/Operations.
* Примечание: если вы настаиваете на пользовательском процессе сборки, ваш процесс сборки будет «обернут» стандартным процессом. - Сборки НИКОГДА не должны выполняться в рабочих системах. Статические части архивируются, а затем развертываются в рабочей среде. Динамические установки с компиляцией кода выполнять не следует. Однако с различиями все в порядке, если они видны, сохранены и «нормализованы» с помощью проверенного «шаблонного» процесса (с использованием только замены «ключ/значение», а не условного кода).
Почему? Сгенерированный код обычно не отслеживается (или не сохраняется), поэтому проблемы нельзя воспроизвести, а сгенерированный код может быть разным для каждой системы, и нет возможности проверить его перед развертыванием. - Насколько это возможно, делайте сборки с пользователями без полномочий root и в каталогах, не принадлежащих root. Использование пользователя root должно быть строго ограничено областями, которые нельзя сделать каким-либо другим способом. Использование пользователя root для «удобства» не является веской причиной.
Почему? Использование root может привести к серьезным проблемам безопасности и проблемам с разрешениями, которые влияют на другие приложения.
Развертывание продукта
- Файлы, которые необходимо развернуть, должны быть размещены на промежуточном этапе или кэшированы как статическая копия. Худший сценарий — это код, который создается динамически или компилируется и устанавливается в один шаг. Исключение: файлы которые генерируются простой заменой ключа/значения, могут быть в порядке, если процесс хорошо протестирован (т. е. с шаблонами и БЕЗ процедурного кода).
Почему? Итак, этот код, который нужно установить, можно проверить перед развертыванием. - Исходные репозитории не следует использовать напрямую для развертывания на всех серверах. Исходные репозитории можно использовать в процессе развертывания, но их следует использовать только один раз на «главном» или «публикационном» сервере.
Почему? Причин много, но в основном это проблема безопасности — каждый сервер будет иметь доступ к исходному репозиторию. Кроме того, исходный сервер репозитория, вероятно, не был предназначен для обработки нагрузки сотен (или тысяч) серверов, обновляющихся одновременно, и исходный репозиторий может быть не настроен для передачи только файлов, которые разные. - Если возможно, разверните серверы разработки так, чтобы они были такими же, как в рабочей среде.
Почему? По крайней мере, разработчики будут видеть, что находится в рабочей среде, и они должны знать, когда вносят изменения. Если разработчики настаивают на том, чтобы этого не делать, то они должны быть обязаны выполнить развертывание в «промежуточных» или «интеграционных» средах, которые настроены так же, как и в рабочей среде, прежде чем передать их в отдел контроля качества. - КК и промежуточные системы должны быть идентичны рабочим. Затем КК проверит все изменения, необходимые для развертывания и тестирования кода от разработчиков. Для вещей, не задокументированных разработчиками (см. все ожидания выше), им необходимо получить информацию от разработчиков или написать ее самим.
Почему? Если этого не сделано, Release Engineering и отдел эксплуатации будет обвинен в слишком медленном развертывании кода, который был проверен на работоспособность. Были времена, когда разработчики не понимали, что файлы, которые они сохранили на сервере, не будут работать в рабочей среде, потому что как получить доступ к этим файлам на всех 200 рабочих серверах? Хорошо, поместите вещи в БД. Хорошо, они запланировали изменения БД? - Разверните продукт на тестовых и промежуточных серверах с помощью тех же инструментов и процесса развертывания, которые используются в рабочей среде.
Почему? Таким образом, различия в конфигурации и процесс развертывания также будет протестирован. QA должен отметить, что им нужно изменить, чтобы заставить продукт работать. (Примечание: не позволяйте инженерам вносить изменения в серверы QA — они могут забыть описать, что они изменили.)
Контрольный список для разработчиков:
Вы используете последнюю версию программного обеспечения и инструментов, потому что:
- это легко (недостаточно веская причина, см. блог: Simple+Made+Easy
- новее лучше (не всегда, часто просто отличается и может привести к ненужным изменениям)
- в нем есть необходимое исправление безопасности (уважительная причина, но можно ли найти это исправление в более старых версиях, находящихся в производстве?)
- у него есть функции, которые делают кодирование «легким» (неуважительная причина)
- у него есть функции, которые делают кодовую базу «более простой» или более стабильной (уважительная причина)
- у него есть функции, которых нет в других версиях или другом существующем коде (уважительная причина, если вы можете это доказать)
При копировании внешнего исходного кода или пакетов:
- Вы записали точный URL-адрес, откуда вы его взяли, домашний каталог и каталог загрузки?
- Вы сохранили (а позже заархивировали) точную, неизмененную копию того, что было загружено? Если есть много незакрепленных файлов, можно собрать их в один файл tar или zip с идентификатором версии данных в имени файла.
- вы задокументировали версию и включили версию с архивными файлами?
- вы включили инструкции по лицензированию, сборке и установке?
- вы заметили зависимости?
Вы решили использовать новую библиотеку или более новую версию существующей библиотеки:
- Встречались ли вы с инженером по выпуску, архитектором и/или операционным персоналом, чтобы узнать, что им нужно сделать для поддержки изменения, т. е. для внедрения изменений в производство?
- добавьте в проект время для этапа «производства». Если код нельзя запустить в производство с помощью существующих процессов развертывания, то это всего лишь прототип или проверка концепции, т. е. он не готов к производству.
Когда вы создаете продукт:
- вы версии ВСЕ файлы, которые вы меняете?
- вы НЕ версионируете объект и другие сгенерированные файлы? (Это экономит место в репо)
- Вы проверяете свои сценарии сборки, файлы Makefile и заметки о сборке?
- Вы включаете информацию о версии в то, что вы строите? Идентификатор версии (или дата) должен быть виден в имени файла, виден в установленном файле и сообщаться динамически с помощью команды или вызова API.
- После того, как определенная версия была установлена в любой среде QA или рабочей среде, при наличии ЛЮБЫХ отличий при следующей установке версия должна быть разными – НЕТ исключений.
- архивируете ли вы созданные файлы в стандартный репозиторий артефактов или помещаете пакеты в стандартные репозитории пакетов, например, Nexus или сервер выпуска?
- если вы вносили улучшения во внешнее программное обеспечение GPL, делились ли вы этими улучшениями с источником?
- включаете ли вы заметки о сборке для всего процесса со ссылками на другую информацию, локальные архивы, другие репозитории, внешние сайты и т. д.? Типичные разделы: исходники ПО, сборка env. подготовка, процесс сборки, процесс упаковки, места выпуска, направления развертывания, направления конфигурации, направления тестирования и направления мониторинга.
- если платформа сборки требует большого количества зависимостей или ее установка и работа занимает много времени, гарантируете ли вы, что сгенерированные файлы идентичны тем, которые создают другие? Кроме того, для запуска конечного продукта в производство необходимо использовать общий сервер сборки. То есть не должно быть НИКАКИХ зависимостей, для которых требуется ваш личный ноутбук или сервер.
Инструментальные тесты:
- Если вам нужно построить сервер на замену, можете ли вы это сделать, даже если пакеты или другое программное обеспечение недоступны (с требуемыми версиями) на внешних серверах?
- Если вы обращаетесь к внешнему серверу за обновлениями, и для этого требуются изменения конфигурации, есть ли у вас разрешение требовать эти изменения? Главным образом, станет ли это производственным изменением?
- Если вы обращаетесь за обновлениями на внешний сервер, заархивировали ли вы новую версию? Знаете ли вы, отличается ли эта версия от последней заархивированной версии? Если вы не знаете, Если вы не сделаете этого, вы можете сломать «цепочку инструментов».
- Если присоединяется новый инженер, можно ли настроить его личную систему разработки и другие инструменты разработки без необходимости изменения систем на последующих этапах жизненного цикла?
Краткое содержание
Это выглядит как много деталей, и это так, но все это можно суммировать одним этим абзацем.
Что вы скопировали, откуда вы это взяли, сохранили ли вы копию (где?), внесли ли вы изменения, есть ли различия в версиях и каково влияние на производственный процесс сборки/выпуска? Не описывайте вещи «в общих чертах» — давайте точные и полные детали или кодируйте процесс сборки/развертывания. Выпуск продукта не считается «готовым», пока клиент его не использует.
Надеюсь, это звучит хорошо, НО лучше определить местоположения для всех этих частей, иначе у вас будет беспорядок. Эти места должны иметь стандартную согласованную структуру, чтобы части могли быть найдены людьми и скриптами автоматизации. Пример обобщенной структуры, которую я использую с 1/2000, см. в разделе Общие структуры каталогов выпусков.
