Арунас Лиуиза , как и многие другие разработчики WordPress, предпочитает разрабатывать свои плагины на GitHub благодаря инструментам совместной работы для отслеживания проблем, слияния и запросов на вытягивание. Размещать и разрабатывать проекты с открытым исходным кодом на GitHub намного проще, чем пытаться получить какое-либо участие от сообщества через репозиторий плагинов Subversion на WordPress.org.
По этим причинам Лиуиза решила создать Deployer — сервис, который позволяет разработчикам плагинов публиковать плагины в каталоге плагинов WordPress.org прямо из GitHub, вообще не используя Subversion. Впервые он представил приложение на WordCamp в Литве в сентябре 2015 года, но пока не продвигал его.
«Я хотел упростить процесс публикации плагинов с GitHub на WordPress.org, — сказал Лиуиза. «У меня в репозитории более 10 плагинов, поэтому я хочу делать все быстро и легко».
В июле прошлого года мы рассмотрели аналогичный сервис под названием Ship , который предлагал простой способ доставки плагинов напрямую с GitHub на WordPress.org. Люиза, которой нужно было поддерживать 10 плагинов, поначалу была в восторге от Ship, но обнаружила несколько недостатков.
«Во-первых, Ship требовал довольно широкого доступа к моей учетной записи GitHub», — сказал он. «GitHub не предоставляет детальный доступ к API, поэтому мне пришлось бы предоставлять Ship доступ ко всем моим репозиториям GitHub, а не только к тому, из которого я хотел публиковаться. Это включает в себя мои личные репозитории.
«Во-вторых, Шипу нужны были мои учетные данные WordPress.org. И поскольку их нужно будет использовать регулярно, они не могли их действительно хешировать и должны были хранить в виде открытого текста. Опять же, это дало бы Ship доступ ко всему в моей учетной записи WordPress.org. Все плагины, все темы, все комментарии, все переводы и т. д.».
Это вдохновило Люизу на создание Deployer с новым подходом, который не требует предоставления доступа и учетных данных.
«По сравнению с Ship, Deployer занимает совершенно противоположную позицию, когда речь идет о запросе доступа», — сказал он. «Там, где Ship запрашивает много привилегий, Deployer почти ничего не просит.
«Deployer не запрашивает привилегий на GitHub. Общедоступные репозитории GitHub могут быть клонированы кем угодно без каких-либо ограничений, поэтому Deployer делает это. Deployer потребуется доступ для настройки WebHook для себя, но вместо того, чтобы запрашивать доступ, Deployer предоставляет пошаговые инструкции для пользователя, как настроить Webhook вручную», — сказал Лиуиза.
Служба Deployer не обрабатывает конфиденциальные данные аутентификации для GitHub или WordPress.org. Вместо этого требуется более ручная настройка.
«Вместо того, чтобы запрашивать учетные данные пользователя WordPress.org, Deployer имеет выделенного пользователя WordPress.org, deployer», — сказал Лиуиза. «Автор плагина должен вручную добавить пользователя-деплойнера в список коммиттеров своего плагина, что позволит этому пользователю зафиксировать код в репозиторий SVN плагина. Это также повышает безопасность, поскольку WordPress.org может идентифицировать все коммиты, сделанные пользователем развертывателя, и откатить их в случае нарушения со стороны развертывателя».
Отправить новую версию плагина с GitHub на WordPress.org так же просто, как пометить новую версию на GitHub. Deployer даже обрабатывает обновления файла readme.txt и каталога ресурсов.
«С технологической точки зрения Deployer — это, по сути, один файл PHP, который анализирует вызовы от GitHub Webhooks, а затем выполняет набор команд оболочки (в основном git и svn) на небольшой машине Linux VPS», — сказал Люиза.
С момента запуска в прошлом году в Deployer было зарегистрировано 34 плагина, хотя Люиза сказал, что не ведет журналы о том, сколько разработчиков регулярно используют его. В настоящее время у него нет планов монетизировать его, но он рад принимать пожертвования .
«Если это не приведет к истощению моих ресурсов (а это маловероятно на данный момент), это всегда будет бесплатный инструмент», — сказала Люиза.
