Тот всплеск активности и суматошной мышиной возни, который очень часто возникает в данный период, не отмечен ни на одной из диаграмм классических процессов разработки, не учтен ни в одном их проектных планов. Тем не менее? встречается этот феномен чрезвычайно часто, связан он с развертыванием (deployment) готового продукта у заказчика и в краткой форме описывается известным афоризмом - «включаем – не работает!».
Разрабатывали мы как-то систему на заказ, с толстым клиентом. Разработали, протестировали, сделали для клиента инсталлятор, привезли заказчику развернули в АСУПе, показали. Заказчик доволен, систему приняли. За выходные АСУП установил клиента на рабочие места по всему предприятию. В подельник пользователи запускают нашего клиента и он не у кого не запускается. Сказать, что был скандал - это ничего не сказать. Заказчик в ярости. Разработчики в дауне. Оказалось, программа при открытии писала в файл в своем рабочем каталоге дату и время своего запуска. На рабочих местах у пользователей не было прав на запись в этот каталог (Program Files). До этого, и у разработчиков, и у тестировщиков, и в АСУПе заказчика программа работала нормально только потому, что все они имели права локального администратора на своих машинах. Все, как один.
Про такие случаи я могу рассказывать долго. Что же делать, для того чтобы их избежать? Самый простой совет – читайте книжки по процессам разработки. В любой книге и любой методологии разработки, вопросам деплоймента уделяется достаточно внимания.
Несколько советов:
- Изучайте рабочую среду (environment), в которой предстоит работать приложению. Начинайте это делать еще до написания первой строчки кода. Начинайте это делать еще до разработки архитектуры приложения. Это важнейший источник не функциональных (системных) требований к приложению. Требования, источником которых является еnvironment, могут перевернуть всю вашу архитектуру с ног на голову. Не верите? Вам нужен пример? Пожалуйста: сервер приложений и сервер БД должны размещаться в разных доменах с разным уровнем безопасности, причем исходящие запросы из домена сервера приложений в домен сервера БД запрещены. Ну как? Не говорите, пожалуйста, что пример идиотский, я это сам знаю. Но он взят из реальной жизни.
- Включайте самое подробное описание environment в проектную документацию. Добивайтесь от заказчика (если работаете на заказ) согласования этого рода требований. Описание такого рода включает схему размещения компонент системы на физических серверах, описание каналов и протоколов сетевого взаимодействия (вплоть до описания портов и направления запросов), описание учетных записей под которыми работают процессы системы, описание методов аутентификации и авторизации для всех сетевых соединений между компонентами системы, описание взаимодействия с внешними системами и т.д.
- Тестируйте приложение в environment максимально приближенном к боевому. Настройте тестовую среду в соответствии с требованиями к развертыванию приложения у заказчика. Потратьте на это время и ресурсы, если не хотите повторить аттракцион, о котором я писал выше.
Создайте и опишите процедуру развертывания (deployment) приложения. Особенно это актуально для тиражируемых решений. Проведите специальное тестирование процедуры развертывания на всех типах environment. (Был неописуемый случай: тестировали большую серверную систему для развертывания под Win2K и под Win2003. А когда приехали к заказчику - оказалось - у него кластер на четыре машины и соответствующая версия OS. Ничего установить не удалось.) - Планируйте затраты на все эти активности в самом начале проекта. Тот, кто создавал Installation Package в VisualStudio знает что это не шутки, и времени на это уходит всегда больше, чем рассчитывали.
Комментариев нет:
Отправить комментарий