Gradle *

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

В предыдущей заметке мы рассмотрели, по каким критериям мы выбирали инструментарий, и почему остановились на gradle/kotlin, а в этой заметке рассмотрим, каким образом используем gradle/kotlin для автоматизации сборки не-JVM проектов. (Есть также перевод на английский.)

Введение

Gradle для JVM-проектов является общепризнанным инструментом и не нуждается в дополнительных рекомендациях. Для проектов за пределами JVM он также используется. Например, в официальной документации описаны сценарии использования для C++ и Swift проектов. Мы используем gradle для автоматизации сборки, тестирования и развёртывания гетерогенного проекта, включающего модули на node.js, go, terraform.

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

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

Хотите узнать, как использовать Gatling через Gradle? Тогда вы по адресу. В последнее время я достаточно часто использую инструмент стресс-тестирования Gatling. Он стал одним из моих излюбленных инструментов для тестирования производительности. На сайте Gatling есть неплохая документация по началу работы. Но она подразумевает загрузку zip-файла, а затем запуск BAT или SH скрипта для запуска Gatling. А затем вам нужно выбрать из списка тест, который вы хотите запустить.

Так что да, было бы намного приятнее делать все вышеперечисленное через Gradle. И естественно, намного удобнее. В частности, если вы хотите запускать Gatling-тесты как часть вашего Continuous Integration. Одним из наибольших преимуществ этого подхода является то, что Gatling может зафейлить вашу CI-сборку, если будет нарушен определенный порог производительности (например, слишком много ошибок или слишком большое среднее время отклика и т. д.).

Если вы хотите запускать Gatling через Gradle, вам понадобится плагин Gatling Gradle.

Это руководство проведет вас через настройку плагина Gradle для нового Gatling-проекта.

Чтобы сделать это руководство еще более удобным для новичков, мы будем производить настройку в IDE (Intellij). После завершения работы по настройке вы можете переключиться на запуск исключительно через командную строку, если вам угодно.

Предупрежу вас с самого начала — я не буду вдаваться в подробности о Gatling в этой статье. Если вы хотите всесторонне познакомиться с Gatling, ознакомьтесь с другой моей статьей «Нагрузочное тестирование с Gatling — Полное руководство».

Всем привет! Я пишу приложения под Android, в мире которого система сборки Gradle является стандартом де-факто. Я решил поделиться некоторыми советами по работе с системой с теми, у кого нет чёткого понимания, как правильно структурировать свои проекты и писать build-скрипты.

Доброго дня, читатель! Меня зовут Стручков Михаил и я Android-разработчик в команде мобильного оператора Yota. 

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

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

Для разработчиков не секрет, что создание нового сервиса влечет за собой немало рутиной настройки: билд скрипты, зависимости, тесты, docker, k8s дескрипторы. Раз мы выполняем эту работу, значит текущих шаблонов IDE недосточно. Под катом мои попытки автоматизировать все до одной кроссплатформенной кнопки "сделать хорошо" сопровождаемые кодом, примерами и финальным результатом.

Если перспективы создания сервисов в один клик с последующим автоматическим деплоем в Digital Ocean звучат заманчиво, значит эта статья для вас.

Привет, Хабр!

Уже пять лет наша команда разрабатывает Тинькофф.Бизнес – мобильный банк для юридических лиц. За это время наше Android-приложение успело набрать целых 200 модулей и 400 тысяч строк компилируемого кода.

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

В этой статье я расскажу и покажу, как мы ускорили билд, отключив Jetifier.

Решаем проблемы с загрузкой Spring Boot Jar

Сталкивались ли вы с проблемой запуска нового загрузочного архива Spring Boot?

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

Привет, Хабр!

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

Процесс создания APK и компиляции кода

Рассматриваемые темы

• Архитектура процессоров и необходимость для виртуальной машины
• Понимание Java виртуальной машины
• Компиляция исходного кода
• Виртуальная машина Андроид
• Процесс компиляции в .dex файл
• ART против Dalvik
• Описание каждой части билд процесса
• Исходный код
• Файлы ресурсов
• AIDL файлы
• Модули библиотек
• AAR библиотеки
• JAR библиотеки
• Android Asset Packaging Tool
• resources.arsc
• D8 и R8
• Dex и Multidex
• Подписывание APK файла
• Ссылки

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

Вот полный список статей из цикла:

1. Создаём аккаунт разработчика, подключаем зависимости, подготавливаем код к внедрению. тык
2. Встраиваем Huawei Analytics. тык
3. Используем геолокацию от Huawei. тык
4. Huawei maps. Используем вместо Google maps для AppGallery. ← вы тут

В чём сложность

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

В предыдущих статьях мы создавали аккаунт разработчика для использования Huawei Mobile Services и подготавливали проект к их использованию. И использовали аналитику от Huawei вместо аналога от Google. В этой статье мы будем встраивать определение геолокации от Huawei.

Вот полный список статей из цикла:

1. Создаём аккаунт разработчика, подключаем зависимости, подготавливаем код к внедрению. тык
2. Встраиваем Huawei Analytics. тык
3. Используем геолокацию от Huawei. ← вы тут
4. Huawei maps. Используем вместо Google maps для AppGallery.

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

Вот полный список статей из цикла:

1. Создаём аккаунт разработчика, подключаем зависимости, подготавливаем код к внедрению. тык
2. Встраиваем Huawei Analytics. ← вы тут
3. Используем геолокацию от Huawei.
4. Huawei maps. Используем вместо Google maps для AppGallery.

Что происходит, кто виноват и что делать

Недавно Google прекратил сотрудничество с Huawei. Это привело к тому, что Huawei на своих новых девайсах уже не может использовать сервисы Google (магазин приложений, геолокация, карты, пуши, аналитика etc), что для пользователя превращает девайс в кирпич. Если бы это не была китайская компания, то, скорее всего, на этом её бизнес, связанный с Android, просто бы прекратился. Но компания китайская, большая и они пошли по пути импортозамещения, в кратчайшие сроки реализовав функционал, аналогичный Google сервисам.

В этой серии статей мы хотим поделиться своим опытом использования Huawei Mobile Services в уже готовом приложении, использующем Google Mobile Services для аналитики (Firebase Analytics), карт и геолокации. Текста получилось довольно много и о сильно разных сервисах, засим статей будет несколько. Начнём мы с основ — регистрации аккаунта разработчика и базовых вещей в коде.

1. Создаём аккаунт разработчика, подключаем зависимости, подготавливаем код к внедрению. ← вы тут
2. Встраиваем Huawei Analytics. тык
3. Используем геолокацию от Huawei.
4. Huawei maps. Используем вместо Google maps для AppGallery.

Если вам интересно узнать технических подробностей, посмотреть код и узнать про подводные камни — добро пожаловать под кат!

Предыстория

Этап первый: настройка для автоматической подписи готового apk

Цели:

• Автоматическая сборка проекта
• Прогон UI автотестов
• Экспорт APK файлов debug и release для последующего ручного тестирования
• Уведомление всех участников команды разработки о результатах

План:

1. Установка и настройка Java JDK
2. Установка и настройка Android SDK
3. Установка отдельного Gradle для дебага
4. Подготовка Android проекта
5. Установка TeamCity Server и Build Agent
6. Настройка TeamCity Project → Build для билда проекта и получения установочного APK
7. Настройка build steps c UI автотестами

Допустим, наше Java приложение размещено на платформе "Heroku", и ему требуется подключиться к HTTP серверу, требующему предоставление Клиентского Сертификата.

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

В данной статье я хочу подробно рассмотреть процесс публикации с нуля Java артефакта через Github Actions в Sonatype Maven Central Repository используя сборщик Gradle.

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