Мы пройдём пять простых шагов, чтобы начать использовать Ant:
Apache Ant – быстрый старт
Мы пройдём пять простых шагов, чтобы начать использовать Ant:
Системы автоматизации сборки
В статье я расскажу, как подключить библиотеку, которой в maven по умолчанию нет, и как подключить другую библиотеку, исходники которой давным-давно потеряны.
Также я опишу, как сделать maven проект, который генерирует артефакт, по совместительству являющийся библиотекой, и как подключить эту библиотеку к другому своему же maven проекту.
Эта статья для тех, кто только начинает осваивать java.
В моей предыдущей статье было сказано, что maven сам скачает все указанные в pom.xml зависимости. А вот что будет, если он какую-нибудь зависимость не найдёт? В таком случае maven скажет, что зависимость не обнаружена и прервёт процесс сборки с ошибкой. Что делать в этом случае?
История с удалением базы конечно затмила все остальные новости про ГитЛаб. Так что если вы пропустили релизный пост про изменения и новые функции в GitLab 8.16, ниже — его перевод:
Наша цель — сделать участие в разработке доступным для каждого. Для этого мы делаем инструментарий GitLab простым в использовании, настройке и обслуживании. В предыдущей версии GitLab мы реализовали простую настройку непрерывной интеграции (continuous integration, CI) и автоматическое развертывание (deploy) в Kubernetes. А в первом релизе нового года мы делаем следующий шаг к нашей цели.
Какая первая ассоциация возникает, когда слышишь словосочетание Microsoft TFS? Что-то большое, неповоротливое и корпоративное. Именно так и было до появления Visual Studio Team Services и выхода MS TFS 2015. Первый — это облачная версия Team Foundation Server, которая опережает в развитии частную (private) версию примерно на три месяца. Одним из главным нововведений обновленного TFS/VSTS стала новая система сборок. Эта система позволяет достаточно просто писать свои шаги сборок, которые могут делать что угодно — от собственно сборки проекта до автоматического заведения дефектов и рассылки нотификаций. Кроме этого новая версия предоставляет развитый REST API для манипулирования задачами, дефектами и практически любыми сущностями в базе данных TFS.
Именно поэтому когда перед нами встал выбор новой системы управления жизненным циклом разработки, мы остановились именно на этой новой версии MS TFS. Мы используем TFS для полного цикла — планирование-разработка-тестирование-развертывание, и, поначалу все шло достаточно гладко. С ростом сложности задач, которые мы ставили перед системой сборки, появлялись и проблемы. К счастью, REST API и собственные шаги сборки позволили их с успехом решить. Далее я расскажу о проблемах и о том, как мы их решили.
В последнем релизе уходящего года мы завершаем наш Мастер-план и хотим показать вам кое-что интересное из того, над чем мы работали.
В GitLab 8.15 появилась фича Auto Deploy – автоматизированная настройка развертывания и приложений для ревью (Review Apps). Для проекта на Ruby on Rails такая настройка займёт меньше минуты. Посмотрите, как это работает, в видео на 1:42.
Вдобавок, доступ к вашим средам (environments) стал быстрее и проще: через терминал непосредственно в GitLab (там же на 5:18)
Мы хотим дать каждому возможность использовать всю мощь контейнеров (containers), непрерывной интеграции и развертывания (continuous integration and deployment, сокращенно CD/CI), приложений для ревью (review apps) и планировщиков контейнеров (container schedulers). В GitLab 8.15 мы взяли на себя всю сложную работу по настройке, и вся она происходит совершенно прозрачно. В демонстрационном видео мы настраиваем и разворачиваем Ruby-приложение с review apps, несколькими средами и чатопсом (chatops, управление инфраструктурой через интеграцию с чатом) на кластер Kubernetes примерно за 12 минут. Без GitLab такая задача обычно занимает дни, если не недели.
Для большинства из нас декабрь — месяц праздников и подарков. GitLab тоже получил в подарок много новых фич.
Сложно представить современную разработку без Continuous Integration. Многие компании выпускают по нескольку релизов в день и прогоняют тысячи тестов. Со времен Jenkins и Travis CI на рынке появилось много самых разнообразных инструментов. Большинство из них работают по модели SaaS — вы платите фиксированную плату за использование сервиса, или за количество пользователей.
Но использование hosted платформ не всегда возможно, например, если нельзя передавать код приложения, или не хочется зависеть от внешних сервисов. В таком случае выручают системы, которые можно установить на своих серверах (self-hosted). Бонусом вы имеете полный контроль над ресурсами и можете масштабировать их согласно вашим потребностям используя, к примеру, amazon ec2.
В этой статье представлен личный опыт использования нескольких opensource self-hosted continuous integration систем. Если вы использовали другие системы, расскажите об этом в комментариях.
Мне хотелось развернуть систему непрерывной интеграции, кросс компилирующую CMake проект написанный на c++ с OpenGL на Raspberry PI. Заодно я хотел посмотреть, не появились ли удобные серверы автоматической сборки, не содержащие в себе питона и не потребляющие сотни мегабайт ram в простое. Одна из целей написания статьи — узнать, не прошёл ли я мимо более хорошего или простого решения :)
TLDR: drone классный, позволяет добавить простенький файл в корень репозитория на github/bitbucket — и получить автоматические билды/тесты/деплой. Прямо как в Travis, но self-hosted.
… или использование TeamCity для сборки *.deb
-пакетов и не только.
Написать статью меня побудило знакомство с модулем tcDebRepository. Я наивно полагал, что "вот сейчас я его подключу, и всё волшебным образом заработает". Как водится, не заработало, и в конце концов был накоплен некий опыт, который захотелось систематизировать.
Статья ни в коей мере не является введением в основы TeamCity и предполагает, что читатель уже знаком и собственно с TeamCity, и с инфраструктурой Debian GNU/Linux. Если вы уже представляете, что такое continuous integration, но ещё ни разу не держали в руках TeamCity — вам, наверное, сюда. О сборке пакетов в Debian можно почитать в Debian New Maintainers' Guide.
Для игр (на случай, если кто-то захочет воспроизвести результаты) использовался сервер TeamCity 10 и 3 агента под управлением Debian 8.0 (Jessie). 3 агента — это лимит в случае TeamCity Professional. Всё ниженаписанное, думаю, без проблем переносится на любой другой дистрибутив на основе Debian GNU/Linux, напр., Astra Linux.
Представьте, что вы делаете ревью кода новой фичи. Помимо качества ее кода вам также интересно, как она будет выглядеть и работать в вашем продукте и насколько удобно будет ее использовать. Раньше вам пришлось бы прервать процесс разработки на собственной рабочей машине, сделать checkout на проверяемую ветку, провести нужные миграции БД и запустить всю рабочую среду (development environment), необходимую для приложения. Теперь вам будет достаточно зайти в мерж-реквест этой ветки на GitLab. Там будет ссылка на уже работающее приложение, развернутое в отдельной среде.
Наконец, ревью завершено, и вы даете коллеге обратную связь в чате. Вместо того, чтобы решать, кто из вас пойдет заводить новую задачу в трекере, вы можете создать задачу и оценить время на ее разработку, не выходя из чата. Аналитика цикла разработки (cycle analytics) сразу учтет данную оценку и будет показывать вам весь путь задачи до выпуска на production, сообщая о возможных узких местах.
Все это и многое другое возможно в новой версии GitLab 8.14. В ней появился учет рабочего времени, приложения для ревью (Review Apps), команды чата (chat commands) и новые возможности аналитики цикла разработки.