Автоматизация программного обеспечения на бюджет

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

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

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

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

1. Как мы можем создать решение, которое легко внедрить с самого начала, но которое может масштабироваться вместе с бизнесом, когда его потребности меняются и растут?
2. Как мы можем построить решение с инвестициями, пропорциональными нашему доступному времени и стадии развития бизнеса?

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

В этой статье я собираюсь основывать решения на гипотетическом бизнесе, который выпускает веб-сайт онлайн-видеообучения, где люди могут войти в систему и приобрести курсы в соответствии со своими интересами. Давайте предположим, что сайт написан на одном из современных динамических языков, таких как PHP, Python или Ruby. Предположим также, что он использует один из наиболее популярных интерфейсов JavaScript, например AngularJS , Ember.js или Backbone.js .

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

Легко ли внедрить решение автоматизации?

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

Что может быть вовлечено в развертывание решения для автоматизации? Ну, вы, вероятно, будете иметь следующие компоненты:

1. Подготовка сервера: Нужно ли устанавливать, останавливать, запускать или перезапускать новые службы?
2. Миграция базы данных: необходимо ли выполнять миграцию базы данных для обновления схемы, возможно, в результате изменений кода?
3. Развертывание кода. Существуют ли новые изменения кода, которые необходимо развернуть, будь то тестирование, подготовка, живая или другая среда?
4. Очистка кэша: необходимо ли очищать каталоги или службы кэша?
5. Учетные данные для аутентификации : какие службы или серверы требуются? Подробная информация об этом может быть предоставлена ​​непосредственно в файле конфигурации или извлечена из среды сервера.
6. Контроль версий : Какая система управляет кодом? Я предполагаю, что весь исходный код версии Git.

Это то, что я бы назвал минимальным набором требований для управления процессом автоматизации. Теперь давайте обсудим, как реализовать такой процесс.

Основное программное решение для автоматизации

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

Давайте начнем с решения, написанного на Perl или в одной из многих оболочек Linux, таких как Bash или ZSH, которое было инициировано хуком Git.

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

Затем возвращенный список файлов можно развернуть на сервере тестирования с помощью стандартных инструментов, таких как SCP , SFTP или Rsync через SSH .

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

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

Положительные

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

Развернутые файлы — это только те, которые Git идентифицирует как измененные. Если что-то пойдет не так, как, например, создание новой ошибки, мы можем быстро отследить, откуда она появилась и кто запустил последнее развертывание. Его можно запускать в любое время, днем ​​или ночью, с одинаковым результатом независимо от того, кто его запускает.

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

Негативы

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

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

Этот подход не потребует дополнительных затрат на внешние услуги или программное обеспечение. Но как насчет затрат времени на разработку? Возможно, это значительно выше, чем плата за внешние услуги или дополнительное программное обеспечение, когда ваши разработчики должны быть сосредоточены на разработке продукта или услуги компании.

Так что насчет чего-то более зрелого, более пригодного для повторного использования и менее требовательного ко времени разработчика

Улучшение подготовки и упрощения развертывания

Давайте проведем рефакторинг решения и исправим некоторые недостатки оригинальной версии. Начнем с замены компонента скрипта, отвечающего за подготовку сервера, на решение с открытым исходным кодом, такое как Ansible , Chef или Puppet .

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

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

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

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

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

Итак, давайте посмотрим на другие решения, чтобы заполнить пробел. К счастью, есть целый ряд доступных инструментов. К ним относятся Deployer , Capistrano и Mina .

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

После создания, опять же с использованием определенной документации, развертывание изменений кода может быть таким же простым, как запуск сценария, такого как deploy <deployment environment> . Все заботятся, так же, каждый раз.

Положительные

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

Негативы

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

Полностью размещенное решение для автоматизации

Но мы могли бы сделать лучше. А как насчет решения, которое требует от нас еще меньше? А как насчет онлайн-решения ? Как только мы сделаем переход к определенной ветке, она будет:

1. Запустите тесты.
2. Если тесты пройдены, начните процесс развертывания.
3. Обеспечьте интеграцию с рядом услуг, таких как те, которые нам нужны.
4. Обеспечьте интеграцию для всех языков программного обеспечения, которые могут нам понадобиться.
5. Обеспечьте диапазон опций уведомления.
6. Делайте все это через профессиональный веб-интерфейс или интерфейс командной строки.

Положительные

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

С помощью выбора конфигурации мы можем использовать предопределенные тестовые конвейеры и конфигурации, такие как PHPUnit для PHP. Мы можем использовать предопределенные конвейеры и конфигурации развертывания и развертываться в таких сервисах, как Heroku , Google AppEngine или Amazon S3 . Мы можем интегрироваться с сервисами уведомлений, такими как HipChat и Slack .

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

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

Негативы

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

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

Вывод

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

бюджет

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

утонченность

Решения становятся все более зрелыми, сложными, обслуживаемыми и масштабируемыми. Более того, они используют инструменты и технологии, которые быстро становятся стандартами де-факто. Дополнительные разработчики могут быть привлечены либо для помощи в их обслуживании, либо для полного управления и развития.

Масштабируемость

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

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

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