Любая софтверная компания рано или поздно приходит к необходимости внедрения непрерывной интеграции, будь это разработка мобильного приложения, создание обычного сайта, или уж тем более, если это сложная микро-сервисная структура.
Ранее я писал, что наша команда занимается разработкой iOS и Android приложений под ключ, включая бекенд и фронтенд. Из этого вытекает острая потребность в наличии масштабируемого процесса дистрибьюции и устоявшихся стандартов по ведению проектов.
Но одно дело, когда у тебя единственный продукт, где можно сделать кое-как, а другое — если каждый месяц появляется новый, с особыми требованиями, большой командой, для которого надо быстро получить CI/CD.
Вы, наверное, подумали, что сейчас будет инструкция по настройке этой самой интеграции, где я поделюсь best practices, скриптами, рекомендациями по инфраструктуре и прочими лайфхаками.
Я тоже так думал.
Но внезапно осознал, что все это просто копипаста в промышленных масштабах, а верное решение лежит не за инструкцией, а за инструментом. Инструментом, который проводит анализ, настройку и сборку проектов самостоятельно. В конце концов, непрерывная интеграция была призвана упрощать жизнь, а не добавлять новых проблем с необходимостью создавать огромные туториалы для написания таких же непомерных по объему скриптов. А потом еще и поддерживать.
По этой причине меня во многом радуют такие сервисы как Travis и Circle за емкость их языка, строгость и доступность инфраструктуры, но тем не менее, этого недостаточно. Все это накладывает обязанности по исследованию их гайдов, требует глубокого понимания особенностей платформы на которую разрабатывается продукт. Уже мало просто уметь делать iOS или Android приложения, надо знать особенности SDK и устройство у них под капотом.
Вы можете сказать, что это нормально, что каждый разработчик должен знать свою платформу и уметь настроить сборку из командной строки, но я не соглашусь. Разработчик должен уметь разрабатывать, писать продукт, знать методы SDK, подходящие библиотеки и уметь их применять. Но никак не разбираться в системах дистрибьюции, скриптовых языках и инфраструктуре. Это как раньше для создания простейшего сайта надо было быть еще и чуть-чуть системным администратором. Немного утрирую, но думаю, вы поняли.
Чтобы не изобретать велосипед, мне предстояло глубокое погружение в интернет, где я рассчитывал найти уже существующие сервисы и испытать их на прочность. Как все знают, идея никогда не приходит только в одну голову.
Я решил взять некий тестовый проект, который буду отдавать на опыты всем найденным сервисам.
Критерием успеха будет способность провести полный цикл непрерывной интеграции — от получения исходного кода до деплоя в Crashlytics.
Для начала мы сосредоточимся на iOS, так как у меня лично, как автора, больше экспертизы в этой сфере, а во-вторых, творение apple всегда славилось головоломной настройкой из-за сертификатов и прочих препятствий.
В качестве образца для тестирования, возьмем старый добрый проект над которым я измываюсь в каждой своей статье. И так, поехали.
После продолжительного дайвинга аж до 20-й страницы гугла, я нашел три продукта, которые подходили под описание. Два из них не запускались в принципе, поэтому мы их даже рассматривать не будем, а третий хоть и работал, но кое-как: не смог определить подходящую версию Xcode, необъяснимо долго собирал Carthage и Cocoapods(для непосвященных — зависимости), и создавалось впечатление, что о кэше любого рода в принципе не слышал. И в итоге зафейлил сборку, как и ожидалось:
Ох уж эти сказочки. Без ложной скромности, я понял, что могу сделать лучше уже сейчас. Потому что кроме одной честолюбивой формулировки, было еще и четкое понимание что у конкурентов работает не так, где, как это исправить и сделать в целом лучше и быстрее.
Вдохновившись идеей вместе с коллегами, которые поддержали задумку, мы сели за разработку прототипа. Опущу напыщенное повествование о том как мы трудились дни и ночи напролет под 'Eye of the tiger', и вместо сочного маркетинга лучше расскажу чего мы добились, какие фишки реализовали и что сейчас реально работает.
Основной целью было полностью автоматизировать настройку непрерывной интеграции для всех, чтобы даже менеджер смог построить в своей компании нормальный бизнес процесс, имея на руках только ссылку в репозитарий и с полным отсутствием технических знаний. Мы даже провели эксперимент, попросив человека не разрабатывающего под iOS настроить непрерывную интеграцию с помощью нашего творения. Мы были очень рады, что у него все получилось. Это был сигнал, что мы движемся в правильном направлении.
Небольшое демо-видео о том как все происходит.
Если сравнивать с Travis, то при равных ресурсах, проекты собираются в 4-5 раз быстрее за счет оптимизации зависимостей и отсутствия необходимости виртуализировать каждого отдельного worker-а и доставлять ему недостающее ПО.
Забыл сказать. Проект решили назвать Buildben. Сначала хотели просто Ben, в честь чудесного нашего офисного кота, а потом родилась игра слов между Big Ben и Build Ben.
Но мы отвлеклись. Вы наверное и так все поняли, что класс, все само делает, кот классный, мы молодцы и все такое. Как говорится — чем удивлять будем?
А вот чем. Мы специально подготовили несколько особенных фич, которые вам понравятся:
В один момент мы осознали, что слишком долго варимся в своем собственном котле, а о сервисе, кроме пары знакомых и друзей практически никто не слышал. Да и средства не резиновые, облако в Amazon само себя не оплатит, знаете ли.
Было решено пойти искать инвестора в лучших традициях стартапов. Долго искать не пришлось, что удивительно, нами заинтересовались и назначили встречу.
Задавали много вопросов, расспрашивали об опыте как команды, какие проекты разрабатывали,кем видим себя через 5 лет, какая наша целевая аудитория, попросили посчитать множество разных сложных цифр, и еще с десяток каких-то странных показателей, параллельно зачитывая лекции о том как правильно жить. В итоге нам сказали следующее:
" — Господа, все здорово, проект интересный. Но есть одно но. Вам нужны пользователи. Без них нет уверенности, что проект действительно востребованный и его стоит развивать. Найдите хотя бы пару десятков людей и компаний, которые захотят воспользоваться вашими услугами, и мы продолжим разговор."
А где технарь может найти технаря, который любит новые продукты и готов пойти в первых рядах? Конечно здесь, на хабре. Мое небольшое знакомство с аудиторией по нескольким написанным статьям показало, что народ здесь хоть и любит покритиковать, но разумный и любознательный.
Я не продавец и маркетолог и не умею красиво говорить о любви, но если ты дочитал до этого момента, то значит тема тебе показалось интересной, и мы будем рады, если ты ею воспользуешься.
У нас есть небольшой посадочный сайт, где можно оставить заявку на бета тестирование, милости прошу. Каждая заявка триггерит мой будильник, и я бегу сразу отвечать. Но, к сожалению, наши ресурсы сейчас сильно ограничены, и пригласить сможем не всех, но постараемся по максимуму.
В конце поста добавлю FAQ, который будет пополняться по мере общения в комментариях.
Вопросы безопасности там можно найти уже сейчас. Это особенно важный аспект, который все понимают.
Еще хочу сказать и даже продублировать, что разработка коробочной версии, которую можно развернуть у себя и забыть про паранойю, находится у нас среди самых приоритетных и мы знаем о её необходимости.
Пожалуй, это все что я хотел рассказать. Буду рад ответить на вопросы, выслушать советы и освятить поподробнее любые аспекты.
Ах да, кстати, вот тот самый кот о котором я говорил:
Чудо, неправда ли?
И по традиции хочу поделиться полезными ссылками:
UPD1: Упс! Неожиданно для нас, мы получили несколько десятков заявок и уверенный список баг репортов.
Вынуждено приостановили прием новых участников до ближайшего понедельника.
Мы уделим внимание всем новым пользователям, спасибо, что вы с нами.
Вопрос: Почему я могу быть уверенным, что мой код никуда не утечет?
Ответ: В первую очередь это основная наша главная ответственность. Мы не читаем ваш код и никто снаружи не может получить к нему доступ, все спрятано в индивидуальную песочницу для каждого проекта. И даже более того, мы его сразу удаляем после сборки, оставляя только логи. Это написано в нашем соглашении о конфиденциальности, которое вы подписываете автоматически регистрируясь в нашем сервисе. Т.е. Мы в соглашении о конфиденциальности пишем, что удаляем исходный код после сборки.
Вопрос: Хорошо, а что насчет доступа к iTunes Connect? Как я могу быть уверен, что вы не сломаете нам приложение?
Ответ: Мы рекомендуем использовать отдельный аккаунт для внешнего доступа, независимо от того используете ли наш сервис или собственный скрипт. Вы можете сами определить границу, куда вы хотите допустить наш продукт. Со своей стороны мы более кого бы то ни было заинтересованны в сохранности информации.
Вопрос: Планируете ли вы выпускать коробочную версию, которую можно было бы развернуть у себя и не беспокоиться за безопасность?
Ответ: Планируем и очень скоро. Это одно из приоритетных направлений.
Ранее я писал, что наша команда занимается разработкой iOS и Android приложений под ключ, включая бекенд и фронтенд. Из этого вытекает острая потребность в наличии масштабируемого процесса дистрибьюции и устоявшихся стандартов по ведению проектов.
Но одно дело, когда у тебя единственный продукт, где можно сделать кое-как, а другое — если каждый месяц появляется новый, с особыми требованиями, большой командой, для которого надо быстро получить CI/CD.
Вы, наверное, подумали, что сейчас будет инструкция по настройке этой самой интеграции, где я поделюсь best practices, скриптами, рекомендациями по инфраструктуре и прочими лайфхаками.
Я тоже так думал.
Начало
Но внезапно осознал, что все это просто копипаста в промышленных масштабах, а верное решение лежит не за инструкцией, а за инструментом. Инструментом, который проводит анализ, настройку и сборку проектов самостоятельно. В конце концов, непрерывная интеграция была призвана упрощать жизнь, а не добавлять новых проблем с необходимостью создавать огромные туториалы для написания таких же непомерных по объему скриптов. А потом еще и поддерживать.
По этой причине меня во многом радуют такие сервисы как Travis и Circle за емкость их языка, строгость и доступность инфраструктуры, но тем не менее, этого недостаточно. Все это накладывает обязанности по исследованию их гайдов, требует глубокого понимания особенностей платформы на которую разрабатывается продукт. Уже мало просто уметь делать iOS или Android приложения, надо знать особенности SDK и устройство у них под капотом.
Вы можете сказать, что это нормально, что каждый разработчик должен знать свою платформу и уметь настроить сборку из командной строки, но я не соглашусь. Разработчик должен уметь разрабатывать, писать продукт, знать методы SDK, подходящие библиотеки и уметь их применять. Но никак не разбираться в системах дистрибьюции, скриптовых языках и инфраструктуре. Это как раньше для создания простейшего сайта надо было быть еще и чуть-чуть системным администратором. Немного утрирую, но думаю, вы поняли.
Исследование
Чтобы не изобретать велосипед, мне предстояло глубокое погружение в интернет, где я рассчитывал найти уже существующие сервисы и испытать их на прочность. Как все знают, идея никогда не приходит только в одну голову.
Я решил взять некий тестовый проект, который буду отдавать на опыты всем найденным сервисам.
Критерием успеха будет способность провести полный цикл непрерывной интеграции — от получения исходного кода до деплоя в Crashlytics.
Для начала мы сосредоточимся на iOS, так как у меня лично, как автора, больше экспертизы в этой сфере, а во-вторых, творение apple всегда славилось головоломной настройкой из-за сертификатов и прочих препятствий.
В качестве образца для тестирования, возьмем старый добрый проект над которым я измываюсь в каждой своей статье. И так, поехали.
После продолжительного дайвинга аж до 20-й страницы гугла, я нашел три продукта, которые подходили под описание. Два из них не запускались в принципе, поэтому мы их даже рассматривать не будем, а третий хоть и работал, но кое-как: не смог определить подходящую версию Xcode, необъяснимо долго собирал Carthage и Cocoapods(для непосвященных — зависимости), и создавалось впечатление, что о кэше любого рода в принципе не слышал. И в итоге зафейлил сборку, как и ожидалось:
Ох уж эти сказочки. Без ложной скромности, я понял, что могу сделать лучше уже сейчас. Потому что кроме одной честолюбивой формулировки, было еще и четкое понимание что у конкурентов работает не так, где, как это исправить и сделать в целом лучше и быстрее.
Работа
Вдохновившись идеей вместе с коллегами, которые поддержали задумку, мы сели за разработку прототипа. Опущу напыщенное повествование о том как мы трудились дни и ночи напролет под 'Eye of the tiger', и вместо сочного маркетинга лучше расскажу чего мы добились, какие фишки реализовали и что сейчас реально работает.
Основной целью было полностью автоматизировать настройку непрерывной интеграции для всех, чтобы даже менеджер смог построить в своей компании нормальный бизнес процесс, имея на руках только ссылку в репозитарий и с полным отсутствием технических знаний. Мы даже провели эксперимент, попросив человека не разрабатывающего под iOS настроить непрерывную интеграцию с помощью нашего творения. Мы были очень рады, что у него все получилось. Это был сигнал, что мы движемся в правильном направлении.
Небольшое демо-видео о том как все происходит.
Если сравнивать с Travis, то при равных ресурсах, проекты собираются в 4-5 раз быстрее за счет оптимизации зависимостей и отсутствия необходимости виртуализировать каждого отдельного worker-а и доставлять ему недостающее ПО.
Забыл сказать. Проект решили назвать Buildben. Сначала хотели просто Ben, в честь чудесного нашего офисного кота, а потом родилась игра слов между Big Ben и Build Ben.
Но мы отвлеклись. Вы наверное и так все поняли, что класс, все само делает, кот классный, мы молодцы и все такое. Как говорится — чем удивлять будем?
А вот чем. Мы специально подготовили несколько особенных фич, которые вам понравятся:
- Кеширование Carthage frameworks в облаке. Что сбилжено однажды, не билдится вновь.
Если кто не сталкивался, то есть такая проблема, что многие фреймворки на github не предоставляют скомпилированный бинарник. А если и предоставляют, то только под определенный Swift. Мы сделали свое хранилище библиотек для каждой версии Swift, которое регулярно пополняется по ходу работы автоматически.
- Утилита для самостоятельной конфигурации кабинета iOS разработчика. При деплое приложения постоянно приходится думать о сертификатах, профайлах, bundle id, всяких entitlements, icloud и прочих. Мы взяли все это на себя и автоматизировали.
- Средство для подготовки Crashlytics приложения. Все, кто работал с Crashlytics знают, что когда создаешь новое приложении или хотя бы просто меняешь его bundle id, приходится его хотя бы раз запустить, чтобы оно создалось. А если надо приложение с новым bundle id проверить? Или просто хочется использовать прелести дистрибьюции в крашлитик без мороки с SDK?
Так вот, все теперь работает как надо. Достаточно в админке выбрать Crashlytics, дальше оно само.
Мы планируем сделать возможность просто вбить логин-пароль от Fabric или, если у вас нет аккаунта, то самим его зарегистрировать без танцев с бубнами.
- Асинхронная сборка. Если что-то можно делать одновременно — мы это делаем. Например, Cocoapods & Carthage устанавливаются параллельно на разных машинах, а потом сливаются воедино. В итоге задачи, которые не требуют мощных ресурсов, выполняются соответствующими микро-процессами, позволяя сосредоточить всю мощь на компиляции.
Следующий шаг
В один момент мы осознали, что слишком долго варимся в своем собственном котле, а о сервисе, кроме пары знакомых и друзей практически никто не слышал. Да и средства не резиновые, облако в Amazon само себя не оплатит, знаете ли.
Было решено пойти искать инвестора в лучших традициях стартапов. Долго искать не пришлось, что удивительно, нами заинтересовались и назначили встречу.
Задавали много вопросов, расспрашивали об опыте как команды, какие проекты разрабатывали,
" — Господа, все здорово, проект интересный. Но есть одно но. Вам нужны пользователи. Без них нет уверенности, что проект действительно востребованный и его стоит развивать. Найдите хотя бы пару десятков людей и компаний, которые захотят воспользоваться вашими услугами, и мы продолжим разговор."
А где технарь может найти технаря, который любит новые продукты и готов пойти в первых рядах? Конечно здесь, на хабре. Мое небольшое знакомство с аудиторией по нескольким написанным статьям показало, что народ здесь хоть и любит покритиковать, но разумный и любознательный.
Я не продавец и маркетолог и не умею красиво говорить о любви, но если ты дочитал до этого момента, то значит тема тебе показалось интересной, и мы будем рады, если ты ею воспользуешься.
У нас есть небольшой посадочный сайт, где можно оставить заявку на бета тестирование, милости прошу. Каждая заявка триггерит мой будильник, и я бегу сразу отвечать. Но, к сожалению, наши ресурсы сейчас сильно ограничены, и пригласить сможем не всех, но постараемся по максимуму.
Важные нюансы
В конце поста добавлю FAQ, который будет пополняться по мере общения в комментариях.
Вопросы безопасности там можно найти уже сейчас. Это особенно важный аспект, который все понимают.
Еще хочу сказать и даже продублировать, что разработка коробочной версии, которую можно развернуть у себя и забыть про паранойю, находится у нас среди самых приоритетных и мы знаем о её необходимости.
Заключение
Пожалуй, это все что я хотел рассказать. Буду рад ответить на вопросы, выслушать советы и освятить поподробнее любые аспекты.
Ах да, кстати, вот тот самый кот о котором я говорил:
Чудо, неправда ли?
И по традиции хочу поделиться полезными ссылками:
- Crashlytics — невероятно удобная и бесплатная система дистрибьюции. Имеет хорошие туториалы и внятное SDK для iOS & Android, рекомендую.
- Mattermost — чат для командной коммуникации, как Slack, только self-hosted и бесплатный. Легко интегрируется со всем чем только можно. Если вы до сих пор обсуждаете деловые вопросы в телеграмме, то вам сюда.
- Fastlane — швейцарский нож для непрерывной интеграции. Если вы самостоятельно занимаетесь деплоем, то это просто must have. Правда, требует определенных знаний Ruby.
UPD1: Упс! Неожиданно для нас, мы получили несколько десятков заявок и уверенный список баг репортов.
Вынуждено приостановили прием новых участников до ближайшего понедельника.
Мы уделим внимание всем новым пользователям, спасибо, что вы с нами.
FAQ
Вопрос: Почему я могу быть уверенным, что мой код никуда не утечет?
Ответ: В первую очередь это основная наша главная ответственность. Мы не читаем ваш код и никто снаружи не может получить к нему доступ, все спрятано в индивидуальную песочницу для каждого проекта. И даже более того, мы его сразу удаляем после сборки, оставляя только логи. Это написано в нашем соглашении о конфиденциальности, которое вы подписываете автоматически регистрируясь в нашем сервисе. Т.е. Мы в соглашении о конфиденциальности пишем, что удаляем исходный код после сборки.
Вопрос: Хорошо, а что насчет доступа к iTunes Connect? Как я могу быть уверен, что вы не сломаете нам приложение?
Ответ: Мы рекомендуем использовать отдельный аккаунт для внешнего доступа, независимо от того используете ли наш сервис или собственный скрипт. Вы можете сами определить границу, куда вы хотите допустить наш продукт. Со своей стороны мы более кого бы то ни было заинтересованны в сохранности информации.
Вопрос: Планируете ли вы выпускать коробочную версию, которую можно было бы развернуть у себя и не беспокоиться за безопасность?
Ответ: Планируем и очень скоро. Это одно из приоритетных направлений.
