Groovy & Grails *

1. Что такое Micronaut

Предыстория

Всем привет! Я хотел бы рассказать историю о страшных конфигах и как их удалось причесать и сделать вменяемыми. Я работаю над довольно большим и относительно старым проектом, который постоянно допиливается и разрастается. Конфигурация задается с помощью маппинга xml-файлов на java-бины. Не самое лучшее решение, но оно имеет свои плюсы — например, при создании сервиса можно передать ему бин с конфигурацией, отвечающий за его раздел. Однако, есть и минусы. Самый существенный из них — нет нормального наследования профилей конфигурации. В какой-то момент я осознал, что для того, чтобы поменять одну настройку, я должен отредактировать около 30 xml-файлов, по одному для каждого из профилей. Так больше продолжаться не могло, и было принято волевое решение все переписать.

Требования

• Наследование и переопределение (или fallback). Должна быть возможность задать некий базовый профиль, унаследовать от него дочерние и переопределить или добавить в них те места, которые необходимо
• Маппинг в java-бины. Переписывать по всему проекту использование конфигурации с бинов на проперти вида mongodb.directory.host не хотелось, использовать map-ы из map-ов тоже.
• Возможность писать в конфиге комментарии. Не критично, но удобно и приятно.

Хотелось бы, чтобы конфиг выглядел примерно так:

name = "MyTest"
description = "Apache Tomcat"

http {
    port = 80
    secure = false
}
https {
    port = 443
    secure = true
}

mappings = [
        {
            url = "/"
            active = true
        },
        {
            url = "/login"
            active = false
        }
]

Как я этого добился — под катом.

• как в Jenkins реализованы Groovy DSL и почему их так много;
• как в Jenkins Pipeline реализованы Groovy Sandbox, доступ к API Java, Script Security и персистентность контекста при рестарте;
• какие архитектурные проблемы это вызывает;
• как можно при всем этом расширять и поддерживать DSL для частных задач.

На Хабре совсем нет информации про TestContainers. На момент написания этой статьи, в поисковой выдаче есть анонсы наших же конференций, и всё. Между тем, в проекте на GitHub у них уже более 700 коммитов, 54 контрибьютора и 5 лет истории. Похоже, все эти пять лет проект тщательно скрывался спецслужбами и НЛО. Настало время выйти из тени на свет.

Чукча — читатель, а не писатель. Поэтому, вместо написания своего текста, я попросил разрешения на перевод соответствующей статьи из блога RebelLabs.

Итак, здесь мы поделимся парой слов о наимоднейшей Java-библиотеке для интеграционного тестирования — TestContainers. Кроме этого, будет немного о том, почему интеграционное тестирование настолько важно для ZeroTurnaround и их требования к интеграционным тестам. И конечно, будет полнофункциональный пример интеграционного теста для Java-агента. Если кто-то никогда в глаза не видел код Java-агента, то сейчас самое время. Добро пожаловать под кат!

Интересная заметка от Madis Pink в блоге ZeroTurnaround RebelLabs. Если кто-то вас разбудит посреди ночи и спросит: «какую фичу в Gradle должен знать каждый?» — с уверенностью отвечай, что это buildSrc. Это особый магический Gradle-проект внутри твоего репозитория, доступный всем файлам build.gradle в виде библиотеки.

Описанный далее подход позволяет писать код на удобном тебе JVM-языке, и результат использовать прямо в своих сборочных скриптах. Как бонус, можно покрыть юнит-тестами особо хитрые моменты в этих скриптах. Добро пожаловать под кат!

Преамбула

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

Рассказывать о долгом и тернистом пути всегда непросто. Однако за последние годы инфраструктура разработки Яндекс.Денег сделала большой шаг в сторону автоматизации самого важного для нас процесса — релиза, о чем просто грех не рассказать. Фактически получилось полноценное решение Continuous Integration и Continuous Delivery на базе связки Bitbucket, Jenkins и Jira.

• поддержка outer join;
• case when… then… end в запросах;
• функции для работы с пространственными(Geospatial) данными;
• возможно отображение данных временных рядов (Time Series) в Grafana;
• ограниченная поддержка подзапросов;
• узлы кластера работающие в режиме только чтения;
• эмуляцией подмножества протокола PostgreSQL 9.5;

• о продвижении продукта без навязчивого расхваливания
• о том, что «стюардессу Java EE пора закапывать»
• о сложностях монетизации open source
• о точном определении слова «стартап»
• о своём дрифте от технологий и борьбе с ним
• о том, чем Artifactory от JFrog лучше конкурентов — и даже о том, чем хуже

Как-то при подготовке одного из докладов про разработку плагинов для Gradle встала задача — как свои поделия потестировать. Без тестов вообще жить плохо, а когда твой код реально запускается в отдельном процессе и подавно, потому что хочется дебага, хочется быстрого запуска и не хочется писать миллион example-ов, чтобы протестировать все возможные кейсы. Под катом сравнение нескольких способов тестирования, которые мы успели попробовать.