Как я могу избежать ловушек при передаче готового продукта команде по установке?

Question

У кого-нибудь есть опыт передачи готового продукта команде по установке?

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

Мы учимся на каждом инциденте, но было бы хорошо, если бы наши клиенты, наша репутация и мой сон были немного более активными.

В частности:

• Какие инструменты вы использовали для улучшения общение / сотрудничество между команды?
• Какие технические решения вы использовали?
• Какие политики вы использовали?
• Кто-нибудь имел успех в написании инструментов проверки после установки?

Edit: Я должен уточнить, что я не говорю о сбоях программного обеспечения, которые должны были быть обнаружены при разработке и / или контроле качества. Проблема заключается в том, что клиент звонит со словами: «Вариант А внезапно недоступен», потому что он не настроен на включение, или «Я не могу войти», потому что сервер аутентификации настроен неправильно. *

Answer 1

Это в основном ответ Ассафа с другим акцентом. Находясь на обеих сторонах развертывания, есть два основных пункта, чтобы ОБЕСПЕЧИТЬ хорошее развертывание.

---

1. Несколько движущихся частей

Это означает, что если у вас есть возможность предоставить несколько файлов и сделать так, чтобы установщик поместил их в определенные папки в производственной среде, или вы могли бы предварительно поместить файлы в структуру папок, а установщик просто скопировал их в корень. Или даже проще, командный файл. Или MSI. Если им нужно запускать сценарии SQL, четко покажите, где они находятся.

По сути, этот шаг сводится к тому, чтобы позволить разработчику создавать сценарии и командные файлы и максимально автоматизировать процесс (хех). Таким образом, развертыватель (который не знает приложение так же хорошо, как вы) не должен прочесть, что он должен делать с тремя оставшимися файлами. (Дух, ты должен поместить их в папки A, B, D и ZZ)

---

2. РУКОВОДСТВО ПО РАЗВЕРТКЕ

Это все заглавными буквами, потому что это превосходит первый шаг. Я говорю о ОЧЕНЬ тщательном руководстве.

Это не должно сказать

" переместить связанные с картой файлы в папку Map-App-Data. "

Стоит сказать

"* Перемещение файлов x, y, z (находится в папке X в вашем пакете развертывания) в папку Map-App-Data (расположена D: \ AppName \ Map-App-Data ) *».

Пройдитесь даже по фразам: «Удаленный доступ к X-серверу, затем сделайте y», потому что вы можете подумать, что понятно, на каком сервере должен быть развертыватель, но для многосерверных настроек он может быть довольно запутанным должно быть сделано где. Наличие такого подробного документа означает, что любой может развернуть, даже тот, у кого не было возможности обучиться тому, что происходит.

---

2,1 План отката

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

---

2.2 Проверка руководства по развертыванию

Пройдите шаги самостоятельно. Или, что еще лучше, попросите коллегу, который НЕ участвует в проекте, попытаться внедрить UAT с вашим гидом, а вы сидите рядом с ними. Везде, где они ошибаются, меняйте руководство. Везде, где развертывание идет не так (ситуации, которые вы видели раньше), добавьте в руководство сноску, объясняющую, почему возникает такая ситуация, и как ее исправить, если это возможно. Крайне важно, чтобы в вашем руководстве по развертыванию не было ошибок, потому что, когда вы пишете руководство по развертыванию, вы, по сути, делаете это для развертывания (потому что знаете, как) И вы получаете бонус от его сна. Но это также означает, что любые ошибки на вас.

Пожалуйста, добавьте комментарии для всего, что я пропустил, и я добавлю это.

Answer 2

• Нет команды установки. Разработчики должны нести ответственность за разработку работающей системы, а не за кучу кусков, которые они бросают через стену для того, чтобы заработали некоторые другие слабые стороны.

• Полностью автоматизированный процесс развертывания / обновления. Развертывание должно потребовать нет ручного принятия решения, потому что кто-то однажды случайно примет неправильное решение.

• Если развертывание завершится неудачно, исправьте проблему автоматизации и перезапустите. Не загоняйте систему в рабочее состояние, потому что люди однажды забудут проверить исправления в репозитории исходного кода.

• Регулярно проверяйте процесс развертывания / обновления во время разработки. Желательно для каждого коммита, как часть непрерывного процесса интеграции.

• Убедитесь, что среда тестирования максимально приближена к рабочей. В идеале единственной разницей должны быть пароли.

• Запускать тесты среды как часть развертывания. Я обычно реализую их в самой системе, чтобы она самостоятельно тестировала и сообщала, что не так с ее средой выполнения.

• Упростите откат неудачных развертываний.

Answer 3

Да. Некоторые основные правила:

1. Всегда доставляйте товар подписанным и опечатанным. Используйте zip (или что-нибудь, что имеет контрольную сумму), не доставляйте отдельные файлы или каталоги.
2. Запишите его на CD и физически передайте. Таким образом, вы узнаете , что у вас есть печатная копия (и резервная копия), которая работает. Вы будете удивлены, насколько легко испортить установку из-за устройств записи компакт-дисков, которые молча повреждают файлы.
3. Команда установки (или QA) должна получать именно то, что получает клиент, не меньше. Предположим, они знают о вашем продукте меньше, чем самый тупой клиент.
4. Естественно, вы всегда должны хранить хранилище всех таких поставок, каталогизированных по версии.
5. Распечатайте любое руководство по установке / развертыванию / пользователю, которое поставляется с версией, и передайте его физически. Как бумага. Даже если документ не изменился со времени последней версии. Я потратил много времени, помогая QA отладить установку, а потом понял, что они использовали неправильное руководство по установке.

Answer 4

Не нацеливаясь на ваши конкретные вопросы, но когда-то была команда разработчиков и тестировщиков, которые развертывали веб-приложение на наборе серверов для тестирования и проверки.

Когда пришло время выпуска, заказчик получил развертываемые файлы и развернул их в соответствии со спецификациями ... На набор серверов ничего не похожи наши серверы разработки.

Был массовый приток ошибок, последовал хаос, клиент свирепствовал, а бедные разработчики не заснули.

Мой совет один из самых очевидных; убедитесь, что среда разработки соответствует производственной среде, чтобы избежать ошибок, специфичных для среды.

Answer 5

После некоторого обсуждения, наша команда разработчиков пришла в голову идея использовать что-то под названием Jump Start. Мы можем упаковать наши RPM и любую необходимую конфигурацию (команды MySQL, изменения в httpd.conf и т. Д.). Как только мы столкнулись с проблемой при установке, мы можем изменить скрипт; это в значительной степени гарантирует, что одна и та же ошибка не будет совершена дважды.

Я обновлю, как только мы действительно начнем использовать этот лайв.