Как написать развертываемое программное обеспечение? - PullRequest
3 голосов
/ 04 апреля 2009

Я - программист Unix, ставший программистом, и потому что это близко и дорого моему сердцу в настоящее время, я хотел услышать о некоторых лучших и худших практиках, с точки зрения написания программного обеспечения, чтобы его было легко развернуть, обновить и поддерживать в долгосрочной перспективе. Я не говорю о долгосрочном обслуживании самого кода; скорее, какие рекомендации вы используете, чтобы ваше программное обеспечение не превратилось в неустановимый беспорядок?

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

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

Что касается «лучшей практики», с точки зрения Unix, мне действительно нравится, когда программное обеспечение является или может быть автономным. Итак, я должен иметь возможность установить приложение в каталог, а затем иметь возможность перемещать этот каталог, не заставляя приложение работать совершенно бесполезно. На самом деле это не занимает больше времени, чем обнаружение путей запуска, и делает мою жизнь системного администратора намного приятнее.

Какими способами вы можете упростить процесс развертывания (как в Windows, так и в Unix) для приложений серверного типа, а также, какие вещи, с которыми вы столкнулись, превратились в настоящий кошмар, когда пришло время вытолкнуть код из двери?

Ответы [ 5 ]

3 голосов
/ 04 апреля 2009

1-Управление внешними хранилищами - если вы предполагаете, что файл должен иметь х, сделайте х настраиваемым. Или используйте относительный путь в качестве одного примера.

2-Не жестко конфигурировать код.

3-Избегайте бинарных зависимостей (COM & DLL Hell Days от Windows)

4-Автоматизируйте это или сделайте так, чтобы обезьяна с мертвым мозгом могла сделать это во сне. Например, теперь все, что мне нужно сделать, это разархивировать файл, и мое веб-приложение развернуто, у меня есть один скрипт sql, который должен быть запущен, и БД обрабатывается. Это не должно занять больше, чем несколько щелчков мышью ... и абсолютно никаких изменений конфигурации не должно быть, все это должно быть написано в сценарии.

2 голосов
/ 04 апреля 2009

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

./configure, make, make install (или соответствующий вариант, если вам нужна другая система сборки) должны быть шагами для установки вашей программы. configure должен найти любые зависимости, включить или отключить любые дополнительные функции и разрешить установку --prefixexec-prefix, bindir и т. Д.) Для выбора подходящих мест установки для различных компонентов. См. Стандарты кодирования GNU для получения дополнительной информации (я не согласен со всеми стандартами кодирования GNU, но совет относительно того, как configure должен работать, хорош).

Включите man страниц, описывающих все параметры командной строки, которые берут ваши программы. Вы можете получить лучшую документацию в другом месте (info, HTML и т. Д.), Но я должен иметь возможность использовать man в качестве краткого справочника по параметрам командной строки. Не походите на GNU и ставьте просто заглушки на некоторых man страницах с указателями на info документы для получения дополнительной информации.

0 голосов
/ 04 апреля 2009

Исповедь: я нажал на этот вопрос, который читал "Как написать плачевное программное обеспечение?" Но теперь я здесь, я должен сделать снимок ...

Интересно, может ли помочь листок из Agile-книги? Работайте в короткие итерации (скажем, от одной до четырех недель) и убедитесь, что вы развертываете не меньше, чем в конце каждой итерации. Таким образом, вы стремитесь действительно развить свое приложение - если это займет слишком много времени, вы больше ничего не сделаете. Проблемы с развернутым приложением возвращаются сообществом пользователей по мере их появления и могут быть приоритетными для действий на последующих итерациях.

0 голосов
/ 04 апреля 2009

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

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

Конечно, если эти тесты можно автоматизировать, они должны запускаться как минимум после каждой ночной сборки; в лучшем случае для каждой сборки Continuous Integration. По крайней мере, сценарий установки продукта или программа установки должны быть запущены, когда пришло время развертывать приложение на компьютерах QA, на которых оно будет проверяться.

0 голосов
/ 04 апреля 2009

Дизайн программного обеспечения и стабильность среды в значительной степени способствуют развертыванию программного обеспечения. Каждое приложение должно быть настраиваемым и иметь привычку для приложений иметь сценарий запуска, который проверяет свою среду и выдает значимые сообщения об ошибках. Контролируйте доступ к серверам и настаивайте на том, чтобы команды, модифицирующие эти серверы, провели надлежащее тестирование в стабильной тестовой среде. Будьте чемпионом тестовой среды. Изменения, которые вносят прикладные группы, должны быть по возможности написаны в сценарии и включать план внедрения, план проверки, план возврата и план проверки возврата. Предоставьте место, где временные файлы и артефакты автоматически очищаются. / u / spool / 01 очищается каждый день. / u / spool05 очищается каждые пять дней. / u / spool30 очищается каждые тридцать дней. Consier статически связывает общий код, если несколько приложений используют один сервер. Избегайте крысиных гнезд ссылок. Избегайте общих креплений. Чемпионы по лесозаготовкам. Изолируйте ваши тестовые системы от ваших производственных систем. Создавайте стандарты, чтобы не писать вне текущего каталога или фиксированного набора каталогов. Создайте четкую связь между развернутым двоичным файлом и системой управления исходным кодом, из которой он получен. Контролируйте свои серверы на предмет неуправляемых процессов, загрузочных дисков и сетевого подключения. Быть суровым по поводу битов разрешения. Найдите способ вознаграждения за работоспособность системы.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...