Практическая автоматизация: Быстрое автоматизированное развертывание

Эффективное использование автоматизации для быстрого развертывания программного обеспечения в различных средах

Автоматизированные сборки нужны не только командам разработчиков - их можно применять и для облегчения перемещения программного обеспечения на всем пути от разработки до выпуска конечной версии. В этой статье из серии Практическая автоматизация эксперт в области автоматизации Пол Дювал описывает, как использовать Ant с Java™ Secure Channel для дистанционного развертывания программного обеспечения в нескольких целевых системах.

Поль Дувол, руководитель технического отдела, Stelligent Incorporated

Поль Дувол (Paul Duvall) является руководителем технического отдела в Stelligent Incorporated, фирма помогает компаниям следить за качеством программных продуктов с помощью эффективных стратегий тестирования и методов непрерывной интеграции, которые позволяют командам раньше и чаще контролировать и улучшать качество кода. Поль также известный автор Инструментария UML™ 2 и в настоящее время является соавтором книги Непрерывная интеграция: улучшение качества программ и уменьшение риска (Addison-Wesley).



19.10.2009

Об этой серии

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

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

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

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

Внедрение может быть безболезненным

Базовый процесс развертывания включает в себя компиляцию, интеграцию изменений в данных (например, таблиц базы данных), удаленное развертывание дистрибутива ПО (например, JAR и WAR-файлов) на других системах и управление ресурсами этих систем. На практике же можно автоматизировать значительно больше аспектов, включая создание установочных носителей, тестирование, создание пользовательской документации и так далее. В этой статье я буду придерживаться основ и расскажу, как можно сделать все эти процессы частью автоматизированного процесса сборки. В частности, будет рассказано о следующих процессах:

  • Развертывание двоичных файлов на удаленных системах
  • Выделение конфигурационных параметров
  • Дистанционное обновление СУБД MySQL
  • Дистанционное конфигурирование сервлет-контейнера Jakarta Tomcat

Автоматизация этих процессов позволяет в итоге доставлять клиентам программное обеспечение быстрее и с меньшей головной болью.


Необходимые инструменты

Главным инструментом для автоматизации развертывания является сценарий сборки; в данном случае это будет Ant. Представленный сценарий Ant будет использовать файлы .properties (разные для разных целевых систем, например, предварительного тестирования (staging) и конечной (production)), взаимодействовать с базой данных MySQL посредством задачи sql из арсенала Ant, а также использовать Java Secure Channel (JSch) для копирования файлов на удаленные компьютеры (с помощью протокола Secure-Copy (SCP)) и остановки и запуска сервисов Tomcat (через SSH).

На рисунке 1 показана обобщенная структура этого процесса. Очень важно, чтобы все имеющиеся артефакты ПО хранились в репозитарии системы управления версиями, потому что идеальный процесс сборки начинается с извлечения исходного кода (и конфигурационных файлов) и их компиляции, далее следует упаковка компонентов на локальной системе, затем дистанционное выполнение SQL-инструкций и после этого развертывание дистрибутива и перезапуск Tomcat.

Рис. 1. Обобщенная структура сборки для дистанционного развертывания
Рис. 1. Обобщенная структура сборки для дистанционного развертывания

Кликните, чтобы увидеть увеличенное изображение

Рис. 1. Обобщенная структура сборки для дистанционного развертывания

Рис. 1. Обобщенная структура сборки для дистанционного развертывания

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


Выделение свойств

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

Правило для параметров

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

В листинге 1 показан простой пример определения свойств в сценарии сборки Ant, который дает возможность передавать файл .properties в качестве системного параметра (например, test.properties), содержащего все значения для конкретной целевой среды. Значением параметра property.file.location может быть путь, например, C:\Documents and Settings\patrick.henry\test.properties. Например, в командной строке можно написать: ant -Dproperty.file.location=C:\Documents and Settings\patrick.henry\test.properties.

Листинг 1. Выделение атрибутов свойств
<property file="${property.file.location}" />

Пример файла .properties для целевой среды приведен в листинге 2. В этом файле значения атрибутов должны (или могут) варьироваться от одной целевой среды к другой, но названия атрибутов всегда должны оставаться теми же.

Листинг 2. Пример атрибутов и соответствующих значений в файле свойств
db.database=brewery
db.username.system=root
db.password.system=sa
db.username=root
db.password=sa
db.hostname=my-hostname.domain.com
db.driver=com.mysql.jdbc.Driver
db.port=3306
db.url.system=jdbc:mysql://${db.hostname}:${db.port}/
db.url=jdbc:mysql://${db.hostname}:${db.port}/${db.database}

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


Упрощение на базовом уровне

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

Цели Ant, перечисленные в атрибуте depends в листинге 3, в обобщенном виде определяют настоящее автоматизированное развертывание. Сначала сценарий удаляет из локальной среды все ранее созданные артефакты (с помощью цели clean), компилирует исходный код, дистанционно создает базу данных, вводит тестовые данные, запускает базу данных и, наконец, дистанционно развертывает WAR-файл в контейнере Tomcat, находящемся в целевой среде.

Листинг 3. Ключевые цели, выполняемые при дистанционном развертывании
<target name="build" 
  depends="clean, compile, refresh-database, remote-tomcat-deploy" />

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


Автоматизация администрирования базы данных

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

Команды языка определения данных (Data Definition Language, DDL), например, удаление существующей базы данных, создание базы данных и создание пользователей базы данных, а за ними такие команды языка манипулирования данными (Data Manipulation Language, DML), как insert, легко могут быть внесены в сценарий и запущены в составе сборочного сценария Ant. Более того, эти команды можно выполнять дистанционно.

Например, если передавать свойство db.url.system (из файла .properties целевой среды), как это показано в листинге 4, сценарий сборки может выполнять команды SQL на удаленной базе данных:

Листинг 4. Сценарий для создания базы данных и добавления данных
<target name="refresh-database" depends="create-database,insert-data" />
<target name="create-database">
  <sql driver="${db.driver}"
    url="${db.url.system}" 
    userid="${db.username.system}"
    password="${db.password.system}"
    src="${database.dir}/create-database.sql"> 
    <classpath>
      <pathelement location="${mysql-connector.jar}"/>
    </classpath>
  </sql>
</target>
...
<target name="insert-data">
  <sql driver="${db.driver}"
    url="${db.url}"
    userid="${db.username}"
    password="${db.password}"
    src="${database.dir}/insert-data.sql">
    <classpath>
      <pathelement location="${mysql-connector.jar}"/>
    </classpath>
  </sql>
</target>

Содержимое файла insert-data.sql, приведенное в листинге 5, вызывается из цели insert-data в листинге 4. Любые SQL-инструкции, будь то DDL или DML, могут быть выполнены аналогичным способом с помощью задачи sql из набора задач Ant.

Листинг 5. SQL-предложения, вставляющие данные
insert into beer(id, beer_name, date_received) values 
  (1, 'Samuel Adams Lager','2006-12-09');
insert into beer(id, beer_name, date_received) values 
  (2, 'Guinness Stout','2006-12-29');
insert into beer(id, beer_name, date_received) values 
  (3, 'Olde Saratoga Lager','2007-02-14');
insert into beer(id, beer_name, date_received) values 
  (4, 'Sierra Nevada Pale Ale','2007-05-14');

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


Распространение и развертывание

Осуществление дистанционного развертывания не сильно отличается от локального развертывания, для него просто требуется другой канал для безопасного копирования всего необходимого из одного места в другое (с машины для сборки на целевую систему). На большинстве предприятий безопасность является одной из приоритетных задач, поэтому простая пересылка файлов с помощью FTP и telnet не всегда подходят. В этом случае эту работу легко выполнить с помощью SCP и SSH. Эти каналы легко использовать из Ant. Я часто применяю задачи sshexec и scp из JSch для дистанционного копирования файлов и запуска команд на удаленных компьютерах.

Переход к рабочей версии

Хотя некоторые подходы к ПО (например, программное обеспечение как услуга - software as a service) изменяют частоту внедрения, переход к рабочей версии является нетривиальным делом. Может потребоваться резервное копирование приложения и базы данных, чтобы можно было вернуть программное обеспечение в первоначальное состояние. Такие действия зачастую могут означать прибыли или потери в миллионы долларов. Процесс автоматизированного развертывания должен быть тщательно протестирован точно так же, как тестируется само программное обеспечение.

Безопасное копирование файлов с помощью SCP

SCP обеспечивает возможность безопасного копирования ресурсов с одной машины на другую. Существует множество инструментов, поддерживающих SCP. Неудивительно, что JSch в Ant использует SCP для копирования ресурсов (например, файлов JAR) без человеческого вмешательства, то есть автоматически.

В листинге 6 задача scp (предоставляемая JSch) копирует (в данном случае) WAR-файл со сборочной системы на удаленный компьютер. Чтобы можно было использовать задачу scp, библиотека JSch (jsch-0.1.36.jar) должна быть в CLASSPATH Ant.

Листинг 6. Безопасное копирование WAR-файла с одной машины на другую
<target name="copy-tomcat-dist">
  <scp file="${basedir}/target/brewery.war" 
  trust="true" 
  keyfile="${ssh.key.file}"
  username="${ssh.username}"
  passphrase=""
  todir="${ssh.server.username}:${ssh.server.password}@${ssh.server.hostname}
  :${tomcat.home}/webapps" />
</target>

При вызове задачи scp необходимо указать местоположение локального файла, предназначенного для копирования, а также местоположение локального файла с закрытым ключом SSH (ssh.key.file в листинге 6, используется для безопасной идентификации). Наконец, необходимо также указать местоположение на удаленной системе (ssh.server.hostname в листинге 6), куда scp должен поместить локальный файл (или файлы).

Дистанционный запуск процессов с помощью SSH

Как и в случае SCP, для запуска команд на удаленной системе часто требуется безопасный механизм, например, SSH. В листинге 7 для остановки и перезапуска контейнера Tomcat, находящегося на удаленном компьютере, используется задача Ant sshexec из JSch. Предполагается, что это та же система, на которую процесс сборки только что безопасно скопировал набор ресурсов, например, WAR-файлов.

Листинг 7. Остановка и запуск удаленного экземпляра Tomcat
<target name="remote-tomcat-stop>
  <sshexec host="${ssh.hostname}"
  port="${ssh.port}"  
  keyfile="${ssh.key.file}"
  username="${ssh.username}"
  passphrase=""
  trust="true"
  command="${tomcat.home}/bin/shutdown" />
  <sleep seconds="${sleep.time}" />
</target>
...
<target name="remote-tomcat-start">
  <sshexec host="${ssh.hostname}"
  port="${ssh.port}"
  username="${ssh.username}" 
  passphrase=""
  trust="true"
  keyfile="${ssh.key.file}" 
  command="${tomcat.home}/bin/startup" />
  <sleep seconds="${sleep.time}" />
</target>

В листинге 7 указаны имя компьютера, на котором находится Tomcat, номер порта для Tomcat (обычно это 8080) и файл закрытого ключа (ssh.key.file), поэтому сценарий сборки может безопасно получить доступ к машине и выполнить специальную команду. Видно, что в этом случае запускается команда shutdown, а за ней команда startup.

Эти последние шаги естественным образом завершают дело: удаленная база данных сконфигурирована, Web-приложение перенесено на удаленную систему, экземпляр Tomcat обновлен. Таким образом, новая версия приложения теперь работает, ее можно тестировать и эксплуатировать.


Автоматизированное развертывание на практике

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

Ресурсы

Научиться

Получить продукты и технологии

  • JSch: загрузить Java Secure Channel для использования безопасных коммуникаций.(EN)
  • Ant: загрузить Ant, чтобы начать создавать программное обеспечение в предсказуемом и воспроизводимом режиме.(EN)
  • Tomcat: загрузить Web-контейнер Tomcat для быстрого создания Web-приложений.(EN)
  • DbUnit: загрузить DbUnit, чтобы использовать XML для управления данными.(EN)
  • Примеры: примеры сценариев из статьи.(EN)
  • IBM trial software: ознакомительные версии программного обеспечения для разработчика, которые можно загрузить со страницы developerWorks.

Обсудить

Комментарии

developerWorks: Войти

Обязательные поля отмечены звездочкой (*).


Нужен IBM ID?
Забыли Ваш IBM ID?


Забыли Ваш пароль?
Изменить пароль

Нажимая Отправить, Вы принимаете Условия использования developerWorks.

 


Профиль создается, когда вы первый раз заходите в developerWorks. Информация в вашем профиле (имя, страна / регион, название компании) отображается для всех пользователей и будет сопровождать любой опубликованный вами контент пока вы специально не укажите скрыть название вашей компании. Вы можете обновить ваш IBM аккаунт в любое время.

Вся введенная информация защищена.

Выберите имя, которое будет отображаться на экране



При первом входе в developerWorks для Вас будет создан профиль и Вам нужно будет выбрать Отображаемое имя. Оно будет выводиться рядом с контентом, опубликованным Вами в developerWorks.

Отображаемое имя должно иметь длину от 3 символов до 31 символа. Ваше Имя в системе должно быть уникальным. В качестве имени по соображениям приватности нельзя использовать контактный e-mail.

Обязательные поля отмечены звездочкой (*).

(Отображаемое имя должно иметь длину от 3 символов до 31 символа.)

Нажимая Отправить, Вы принимаете Условия использования developerWorks.

 


Вся введенная информация защищена.


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=40
Zone=Технология Java
ArticleID=438162
ArticleTitle=Практическая автоматизация: Быстрое автоматизированное развертывание
publish-date=10192009