Время от времени кто -то спрашивает мое мнение о том, что лучше всего развернуть код на сервере. О этой теме можно сказать, поэтому я обычно разочаровываю индикатора, потому что у меня редко бывает простой ответ для них. Как и многие другие вещи в жизни, лучший способ сделать это зависит от точной ситуации. Шкала, в которой вы работаете, тип используемых вами серверов, тип приложения, который вы развертываете, требуется уровень безопасности, инфраструктура, которую вы используете и т. Д.
Я обычно делаю, это передать несколько основных правил, которые я всегда следую в каждом сценарии.
Автоматизированное тестирование
Первое правило также то, что большинство людей выходят или откровенно игнорируют Но это также, вероятно, самое важное: должно быть какое-то автоматическое тестирование, которое работает до того, как все остальное и останавливает процесс развертывания, если что-то пойдет не так.
Модульное тестирование, интеграционное тестирование, функциональное тестирование — делайте все, что хотите но Никогда , когда-либо Развертывание кода, которое не тестируется автоматическим способом.
Я не могу подчеркнуть, насколько это важно. Это дает вам спокойствие, потому что вы знаете, что если ошибка введена где-то, есть очень хороший шанс, что он будет пойман до достижения продукции (при условии, что вы делаете ваши тесты правильно).
Большинство людей думают, что это самое большое преимущество тестирования, и это огромное преимущество — но есть что-то еще, что я считаю еще большей выгодой, хотя это гораздо более тонкий.
Не обременять беспокойство о том, чтобы что -то разбить на живых серверах, дает разработчикам людям душевное спокойствие. Удалив этот вес от плеч для разработчиков, они могут быть более продуктивными, потому что они могут свободно манипулировать своим кодом без (столько же) бояться нарушать все.
Мы не пишем тесты (только), чтобы поймать ошибки до того, как они достигли производства — мы пишем тесты, чтобы мы могли быстрее рефакторировать и итерацию.
Здесь можно сказать многое другое о автоматическом тестировании, но внизу — это: сделать это, нет оправданий.
Автоматизировать все вещи
Это еще одна очень распространенная ошибка: обновление производственного кода путем входа в сервер и запустив git pull Отказ Это немного, как играть российскую рулетку с более чем одной пулей в пистолетной камере.
Автоматизация все означает, что больше всего Вы нажимаете кнопку, чтобы вызвать развертывание. С этого момента все должно произойти автоматически. Очень распространенная настройка состоит в том, чтобы набрать крючок некоторой видимости в репозитории кода, и когда кода нажата, срабатывание развертывания и сценарий выполняется.
Почему это важно? По очень простой причине: мы люди. Люди делают ошибки, тогда как сценарий развертывания является детерминированным: он будет запускать так же каждый раз. Если ваше развертывание состоит только из нескольких измененных файлов из вашего репозитория кода, это не имеет большого значения. Но, поскольку вы добавляете больше шагов к этому, вероятность ошибки, даже на что-то простое, становится выше.
Например, давным-давно я работал над проектом, в котором проводник проекта настаивал на том, что мы вручную развернули наш код. Он сказал, что мы будем чувствовать себя более ответственным и были бы более осторожны. Я не хотел брать на себя шансы, поэтому я написал сценарий, чтобы сделать это для меня, но большинство моих коллег делали это вручную. Они сделали это десятки раз без проблем, но один раз, когда один из них забыл управлять миграциями базы данных, и несколько часов прошло, прежде чем кто-то заметил, что возникла проблема. К тому времени была тонна поврежденных данных, и у всех нас было супер веселое время, выздоравливая с мероприятия.
Итак, сделайте себе одолжение и укажите искушение делать вещи вручную. Слишком легко испортить это даже в простых сценариях. Напишите скрипт, чтобы автоматизировать свое развертывание с самого начала вашего проекта, даже если это просто простой Git Pull Отказ В конце концов он будет расти, и если вы это сделаете, вы никогда не поймете, насколько вы благодарны, что вы это сделали.
Развертывание кода
Вот где все становится мутным, потому что это зависит от того, что вы развиваете. Например, если вы развертываете кусок Python или Ruby, вы можете иметь простой скрипт, который работает Git Pull или что-то подобное и перезапускает ваш веб-сервер или долгоживущие процессы. Но если вы строите заявку Java, это немного более вовлечено, потому что новый .jar Файл должен быть построен и whatnot. Если вы используете базу данных, вам может потребоваться запустить некоторые миграции базы данных. Вам, вероятно, нужно компилировать и публиковать некоторые статические файлы. Есть много переменных.
У меня были Ткань или Капистрано Сценарий, который содержит все шаги, я бы сделал, если бы я был вручную развертываю код. Этот скрипт вызван Travisci , Circleci , Drone.io , Дженкинс Или любой непрерывный инструмент интеграции, который я использую, когда я нажимаю код на мой репозиторий (обычно к определенной ветке, как Master ). Он подключается к серверам и выполняет серию предварительно запрограммированных шагов для получения нового кода из репозитория, публиковать статические активы, запустить миграцию базы данных, перезапустить серверы, поверните DNS для нескольких серверов и т. Д.
Многие люди делают простой Git Pull Но так, как я делал это, бежал Git Fetch Origin Сначала с последующим git reset -gard Head . Таким образом, я гарантирую, что если кто -то совершил заглавный грех вручную вручную на сервер и изменение живого кода, эти изменения исчезли.
В настоящее время я предпочитаю использовать Docker вместо сценариев, которые меняют вещи на серверах. Инструмент CI делает работу по созданию контейнеровоза и толкает его в репозиторий. Тогда требуется обновление запущенных служб на серверах или размещенном сервисе, как Google Cloud Run , Google Kubernetes Engine , AWS ECS , и т.д.
Единый источник правды
Для вашего кода должен быть один «источник правды». Это означает, что все, что выходит из-за пределов репозитория, следует игнорировать, отбрасывать и не разрешено на производственных серверах.
Если кто-то решит исправить ошибку непосредственно в текущем коде, они должны получить 5 ресниц для каждой строки измененного кода. Если они это сделают, а затем не применяйте те же изменения в репозитории, то это еще одна 20 ресниц:-)
Это потому, что в следующий раз, когда код будет развернут, патч будет перезаписан, и ошибка вернется. Или если вы используете равнинную Git Pull Метод, развертывание может сбиться, потому что в копии хранилища в копии хранилища неперерабатываемых изменений в копии хранилища сервера.
Последние мысли
Я надеюсь, что это даст вам несколько идей. Опять же, есть много, что можно сказать об этой теме, и это полностью зависит от вашей конкретной ситуации, поэтому невозможно придумать «Лучшим путем» для развертывания программного обеспечения.
Если это тема, которая вас интересует, я настоятельно рекомендую вам прочитать сообщение Зака Холмана под названием «Как развернуть программное обеспечение» Отказ Это одна из лучших статей, которые я когда-либо читал об этом. Это долго, но стоит каждую минуту.
Как насчет вас, как вы развертываете программное обеспечение? Каковы ваши основные правила?
Оригинал: «https://dev.to/borfast/basic-rules-for-software-deployment-3abf»