Что такое общие методы для развертывания крупномасштабных систем?

Насколько я понимаю, вы в основном спрашиваете о лучших практиках и инструментах для релиз-инжиниринга AKA-релевантность - важно знать "термин искусства" для предмет, потому что это значительно упрощает поиск дополнительной информации.

Система управления конфигурацией (CMS - также известная как система контроля версий или система контроля версий) незаменима для современной разработки программного обеспечения; если вы используете одну или несколько IDE, также хорошо иметь хорошую интеграцию между ними и CMS, хотя это больше проблема для целей разработки, чем для целей развертывания / обновления.

С точки зрения релевантности, ключевой момент о CMS заключается в том, что она должна иметь хорошую поддержку «ветвления» (под любым именем), потому что выпуски должны производиться из «ветки выпуска» где весь разрабатываемый код и все его зависимости (код и данные) находятся в стабильном «снимке», из которого по желанию может быть воспроизведена точная идентичная конфигурация.

Потребность в хорошей поддержке ветвления может быть более очевидной, если вы должны поддерживать несколько веток (настроенных для разных целей, платформ и т. д.), но даже если ваши выпуски всегда строго в единой линейной последовательности, передовой опыт по-прежнему диктует создание ветки выпуска. «Хорошая поддержка ветвления» включает в себя простоту слияния (и «разрешение конфликтов», когда в файл вносятся разные изменения), «выбор вишни» (взятие одного патча или набора изменений из одной ветки или заголовка / ствола и его применение к другая ветвь) и т. д.

На практике вы начинаете процесс выпуска с создания ветки выпуска; затем вы запускаете исчерпывающее тестирование в этой ветке (обычно НАМНОГО больше, чем то, что вы запускаете каждый день в непрерывной сборке, включая обширное регрессионное тестирование, интеграционное тестирование, нагрузочное тестирование, проверку производительности и т. д., и, возможно, даже более дорогостоящие процессы обеспечения качества, в зависимости от ). Если и когда исчерпывающее тестирование и контроль качества обнаруживают дефекты в версии-кандидате (включая регрессии, снижение производительности и т. Д.), Они должны быть исправлены; в большой команде разработка head / trunk может продолжаться, пока выполняется QA, откуда возникает потребность в простоте выбора вишен / слияния / и т. д. (независимо от того, хотите ли вы выполнить исправление на голове или в ветке выпуска, его еще нужно слить с другой стороной ;-).

И последнее, но не менее важное: вы » re НЕ получает полной отдачи от вашей CMS, если вы каким-то образом не отслеживаете с ее помощью «все», от чего зависят ваши выпуски - проще всего было бы иметь копии или жесткие ссылки на все двоичные файлы для инструментов, необходимых для создания вашего выпуска, и т. д., но это часто может оказаться непрактичным; поэтому, по крайней мере, отслеживайте точные выпуски, версии, исправления и номера тех инструментов, которые используются (операционная система, компиляторы, системные библиотеки, инструменты, которые предварительно обрабатывают изображения, звуковые или видеофайлы в окончательной форме и т. д. и т. д.). Ключ заключается в том, чтобы при необходимости точно воспроизвести среду, необходимую для восстановления точной версии, предложенной для выпуска (иначе вы сойдете с ума, отслеживая тонкие ошибки, которые могут зависеть от изменений сторонних инструментов. поскольку их версии меняются; -).

После CMS, Второй по важности инструмент для обновления - это хорошая система отслеживания проблем, в идеале хорошо интегрированная с CMS. Это также важно для процесса разработки (и других аспектов управления продуктом), но с точки зрения процесса выпуска важность средства отслеживания проблем заключается в возможности легко документировать, какие именно ошибки были исправлены, какие функции были добавлены, удалены и т. Д. или изменены, и какие изменения в производительности (или других наблюдаемых пользователем характеристиках) ожидаются в новом предстоящем выпуске. Для этой цели ключевой «передовой практикой» в разработке является то, что каждый набор изменений, который фиксируется в CMS , должен быть связан с одной (или несколькими) проблемой в системе отслеживания проблем: в конце концов, должна быть какая-то цель этого изменения (исправить ошибку, изменить функцию, оптимизировать что-то или какой-то внутренний рефакторинг, который должен быть невидим для пользователя программы); аналогично, каждая отслеживаемая проблема, помеченная как «закрытая», должна быть связана с одним (или несколькими) наборами изменений (если только закрытие не относится к типу «не будет исправлять / работать должным образом»; проблемы, связанные с ошибками и т. д. в сторонних компонентах , которые были исправлены сторонним поставщиком, с ними легко справиться аналогичным образом, если вам удастся также отслеживать все сторонние компоненты в CMS, см. выше; если вы этого не сделаете, по крайней мере, должен быть текст файлы в CMS, документирующие сторонние компоненты и их развитие, снова см. выше, и их необходимо изменить, когда какая-то отслеживаемая проблема на стороннем компоненте закрывается).

Автоматизация различных процессов обновления (включая сборку, автоматическое тестирование, и задачи развертывания) является третьим по важности приоритетом - автоматизированные процессы намного более продуктивны и повторяемы, чем просьба какого-нибудь бедного человека вручную выполнить список шагов (для достаточно сложных задач, конечно, рабочий процесс автоматизации может потребоваться " ввести человека в петлю "). Как вы догадываетесь, здесь могут помочь такие инструменты, как Ant (и SCons и т. Д. И т. Д.), Но неизбежно (если только вам не повезет с очень простыми и понятными процессами). ) вы обнаружите, что обогатите их специальными скриптами и т. д. (поможет какой-нибудь мощный и гибкий скриптовый язык, такой как perl, python, ruby ​​и т. д.). «Механизм рабочего процесса» также может быть полезен, когда рабочий процесс выпуска достаточно сложен (например, с участием определенных людей или их групп » s прошел гладко (включая сохранение и резервное копирование БД в ее новом состоянии, если необходимо), система снова открыта для общего использования.

Если вам нужно обновить «живую» систему без простоев, это может произойти где угодно от легкого неудобства до систематического кошмара. В лучшем случае транзакции достаточно короткие, и синхронизация между состоянием, установленным транзакциями, может быть немного задержана без ущерба ... и у вас есть разумное изобилие ресурсов (ЦП, хранилище и т. Д.). В этом случае вы запускаете две системы параллельно - старую и новую - и просто убедитесь, что все новые транзакции нацелены на новую систему, позволяя старым завершиться в старой системе. Отдельная задача периодически синхронизирует «новые данные в старой системе» с новой системой, поскольку транзакции в старой системе завершаются. В конце концов вы можете определить, что никакие транзакции не выполняются в старой системе, и все изменения, которые там произошли, синхронизируются с новой - и в это время вы можете окончательно выключить старую систему. (Вы, конечно же, должны быть готовы к «обратной синхронизации», если потребуется откат изменения.)

Это «простой, приятный» крайний вариант для обновления системы в реальном времени; с другой стороны, вы можете оказаться в такой чрезмерно ограниченной ситуации, что можете доказать, что задача невозможна (вы просто не можете логически удовлетворить все заявленные требования с данными ресурсами). Длительные сеансы, открытые в старой системе, которые просто не могут быть прерваны - ограниченные ресурсы, которые делают невозможным параллельную работу двух систем - основные требования для синхронизации каждой транзакции в реальном времени и т. Д. все может сделать вашу жизнь несчастной (и, как я заметил, в крайнем случае, может сделать поставленную задачу абсолютно невыполнимой). Две лучшие вещи, которые вы можете сделать с этим: (1) убедитесь, что у вас достаточно ресурсов (это также спасет вашу кожу, когда какой-то сервер неожиданно выйдет из строя ... у вас будет еще один, чтобы запустить его, чтобы встретить чрезвычайную ситуацию! -); (2) учитывать это затруднительное положение с самого начала, при первоначальном определении архитектуры всей системы (например: предпочитать краткосрочные транзакции долгоживущим сеансам, которые просто не могут быть "моментальным снимком", закрыты и легко перезапущены из моментального снимка. ", - один хороший архитектурный указатель; -).

(1) убедитесь, что у вас достаточно ресурсов (это также спасет ваш скин, когда какой-то сервер неожиданно выйдет из строя ... у вас будет еще один, чтобы запустить его, чтобы встретить чрезвычайную ситуацию! -); (2) учитывать это затруднительное положение с самого начала, при первоначальном определении архитектуры всей системы (например: предпочитать краткосрочные транзакции долгоживущим сеансам, которые просто не могут быть «моментальными снимками», закрыты и беспрепятственно перезапущены из моментального снимка. ", - один хороший архитектурный указатель; -).

(1) убедитесь, что у вас достаточно ресурсов (это также спасет ваш скин, когда какой-то сервер неожиданно выйдет из строя ... у вас будет еще один, чтобы запустить его, чтобы встретить чрезвычайную ситуацию! -); (2) учитывать это затруднительное положение с самого начала, при первоначальном определении архитектуры всей системы (например: предпочитать краткосрочные транзакции долгоживущим сеансам, которые просто не могут быть «моментальными снимками», закрыты и беспрепятственно перезапущены из моментального снимка. ", - один хороший архитектурный указатель; -).