Всем привет! В моей текущей работе у нас была проблема с нашим CI / CD, и мы начали искать альтернативы. Мы проверили различные платформы, такие как CircleCI, Bitrise и другие. Тем не менее, процесс обращения к руководству верхнего уровня с просьбой добавить это в качестве поставщиков был немного медленным и утомительным, поэтому, поскольку у нас уже был GCP в качестве поставщика, мы решили попробовать GCP Cloudbuild.

Cloudbuild - это инфраструктура, которая позволяет запускать сборки для ваших проектов. Цена была разумной, поэтому мы решили потратить время на то, чтобы перевести все наши Android CI / CD в облачную сборку.

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

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

Примечание: статьи, на которых основан этот пост.

https://ryanharter.com/blog/cloud-build/ https://medium.com/dailymotion/run-your-android-ci-in-google-cloud -build-2487c8b70ccf

Во-первых, давайте включим GCP KMS.

Сначала нам нужно перейти в консоль GCP, создать наш новый проект и включить KMS. Вы должны перейти в Безопасность → Криптографические ключи.

Примечание. KMS означает «Служба управления ключами».

Создание связки ключей и криптоключа

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

«Yourkeyringname» - это имя вашей связки ключей, и вы должны заменить ее на то, что вам больше всего подходит, а флаг -location = global означает, что эта связка ключей доступна во всех регионах вашего проекта.

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

«KEYNAME» - это имя ключа, который вы хотите создать, а флаг-keyring указывает, к какой связке ключей он будет принадлежать, поскольку мы используем в качестве примера «yourkeyringname», что он будет ему принадлежать.

Шифрование переменной

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

Это означает, что вы зашифруете ваш файл my_variable.txt и преобразуете его в my_variable_encrypted.txt, используя связку ключей и криптоключ. После этого вам нужно создать base64 из вашей зашифрованной переменной, и это может быть достигнуто с помощью следующей команды:

Если вы используете macOS, вы можете использовать:

В Linux это команда:

Результат этого процесса будет примерно таким:

Примечание. Это пример. Ваш base64 не будет таким же.

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

Создание нашего AndroidBuilder

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

В этом Dockerfile мы делаем следующее:

  • Получите конструктор javac из GCR (Google Container Registry).
  • Обновите систему.
  • Загрузите зависимости.
  • Задайте для нашего «аргумента сборки» имя СЕКРЕТНО.
  • Установите ANDROID_HOME в качестве переменной среды.
  • Скопируйте наш скрипт gradle-build (это небольшой скрипт, который помогает нам хранить кеш Gradle, чтобы последующие сборки могли быть быстрее).
  • Загрузите инструменты android sdk, установите наши инструменты как переменную среды и, наконец, установите Android SDK.

Это сценарий gradle-build, который упоминается в файле Dockerfile.

Примечание. Этот Dockerfile и скрипт gradle-build основаны на этой статье, которая мне очень помогла. Я только добавил несколько инструкций, последнюю версию платформы Android, инструменты сборки, инструменты платформы и строку ARG SECRET.

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

В качестве последней части этого шага мы собираемся создать cloudbuild.yaml, который будет собирать наш контейнер и загружать его в реестр контейнеров Google. В этом файле cloudbuild.yaml мы собираемся выполнить команду, которая строит контейнер. Вот где мы собираемся запустить наш Android-проект. В этом cloudbuild.yaml мы передаем наш секрет и используем base64, который мы сгенерировали ранее, вот как это будет выглядеть.

В этом файле мы создаем контейнер Docker и передаем наш секрет как build arg. Вы можете видеть, что мы используем двойной знак доллара, чтобы избежать замен в облачной сборке, которыми, например, является $ PROJECT_ID, затем мы объявляем, что собираемся использовать секрет в конце нашего cloudbuild.yaml . Не забудьте заменить «yourprojectname», «yourkeyring», «yourcryptokey» и base64 в предыдущем файле.

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

Важно: если вы получаете сообщение об ошибке из-за того, что у реестра контейнеров нет разрешения на расшифровку, вам необходимо перейти в консоль GCP, выбрать Cloudbuild, перейти к настройке и скопировать адрес электронной почты своей служебной учетной записи, перейти к Безопасность → Криптографические ключи → Выберите свой ключ → Нажмите кнопку добавления участника на правой панели, добавьте его в качестве участника и выберите роль дешифрования криптографических ключей.

Файл cloudbuild в нашем проекте для Android

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

Во-первых, мы собираемся создать пару сегментов хранилища GCP, а сегменты хранилища - это хранилища объектов, предоставляемые Google Cloud Platform. Другими словами, это помогает нам хранить вещи. В нашем случае это будет полезно для нашего кеша Gradle и apks.

Чтобы создать его, мы собираемся открыть терминал и ввести следующую команду.

В нашем cloudbuild.yaml мы собираемся описать следующие шаги:

  • Скопируйте наш кеш в корзину GCP Storage Bucket, используя образ gsutil из реестра контейнеров Google. GCP предоставляет этот образ, поэтому нам не нужно создавать собственное.
  • Запустите задачу KtLintCheck на нашем ранее созданном AndroidBuilder.
  • Запустите задачу Detekt в нашем AndroidBuilder.
  • Всегда запускайте наш модульный тест в AndroidBuilder.
  • Соберите наш Apk.
  • Сохраните кеш.
  • Храните наши файлы apks в ведре для хранения.
  • Наконец, мы установили тайм-аут для сборки на 1200 секунд.

Примечание. Ktlint - это инструмент линтинга для Kotlin, и вы можете узнать о нем больше в этой замечательной статье Нейта Эбеля. С другой стороны, Detekt - это инструмент статического анализа кода для Kotlin, и вы можете прочитать о нем здесь.

Настройте триггеры.

Теперь мы хотим настроить триггеры сборки, чтобы каждый раз, когда мы нажимаем ветку, мы могли запускать нашу сборку, чтобы убедиться, что все в порядке. Для этого нам нужно перейти на console.google.com, выбрать наш проект, перейти в меню навигации, выбрать облачную сборку, триггеры, подключить наш репозиторий, если вы еще этого не сделали, а затем нажать опцию создания триггера. . Это выглядит так.

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

Вы также можете опробовать свои сборки локально, используя cloud-build-local.

Протестируйте свою сборку локально

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

Примечание. Вам необходимо установить сначала cloud-build-local с помощью следующих команд.

Подробнее об этом вы можете прочитать здесь.

Куда мы отправимся отсюда

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

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

Что вы можете извлечь из этого

Если вы ищете альтернативу circleCI, bitrise или другим, и вы не боитесь терминала и изучения нового (при условии, что вы похожи на меня и ничего не знаете об облачной сборке), облачная сборка - это круто. Конечно, у него нет красивого пользовательского интерфейса / пользовательского интерфейса одного поставщика непрерывной интеграции. Но он очень хорошо справляется со своей задачей. Так что это зависит от ваших потребностей.

Вот и все

Если у вас есть вопросы, предложения или улучшения, оставьте, пожалуйста, комментарий 😄. Вы также можете связаться со мной через Twitter @ gvetri18.

Первоначально опубликовано на https://www.codingpizza.com 30 апреля 2020 г.