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

В версии GitLab 9.1 появились канареечные развертывания. Они позволяют вам развертывать новый код на небольшой части вашей инфраструктуры. Если обнаружатся проблемы, они успеют затронуть лишь малую часть пользователей, и вы сможете легко откатиться к предыдущей версии. Это быстрая обратная связь от боевого окружения.

С новой фичей Service Desk ваши пользователи могут отправлять свои вопросы и сообщать о проблемах на специальный адрес электронной почты, отдельный для каждого проекта. По письму от пользователя Service Desk заводит конфиденциальную задачу (issue) в вашем проекте. Когда кто-либо комментирует задачу, пользователь получает этот комментарий в ответном письме. Это — встроенный непосредственно в GitLab канал обратной связи от пользователей.

Недавно мы выпустили GitLab 9.0, через 18 месяцев после выпуска версии 8.0. За это время мы сделали множество значительных изменений в GitLab, выпуская новую версию 22 числа каждого месяца. Давайте кратко подведем итоги, к которым мы пришли с выпуска 8.0, и посмотрим, как старые фичи соотносятся с новыми из 9 версии. Или вы можете перейти к фичам, появившимся в 9.0.

Сейчас мало кого удивишь инструментами управления зависимостями проекта вроде npm, composer, bundler, pip, maven, cargo и других. Их общий недостаток — невозможность управлять непосредственно средой выполнения. Такая задача решается через nvm, php-build, rvm, virtualenv, sdkman, rustup и прочие глобальные "манагеры" версий runtime, обычно написанные под Bash/Zsh.

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

Далее разброд и шатание настегает Continuous Integration & Delivery, где ручные танцы с бубном установки инструментов и активирования конкретных версий совершенно не приветствуются, а в идеале требуется в принципе максимально абстрагироваться от используемых технологий и довести процесс до примитивных нейтральных команд: подготовить к релизу, затегить, скачать, подготовить, построить, упаковать, выложить, проверить, одобрить(подписать), выкатить.

Тут сам собой напрашивается инструмент, унифицировано работающий поверх уже существующих технологий,
который из себя и представляет FutoIn CID — FutoIn Continuous Integration & Delivery tool.

Сегодня существует множество task-runner'ов, boilerplates для быстрого старта разработки, но зачастую даже в этом случае приходится дорабатывать, писать, разбираться в куче настроечных файлов, и корень проекта зачастую похож на сборище разнообразных конфигов. Работая в разных проектах даже в рамках одной компании зачастую в каждом проекте все устроено по-своему и перед тем как начать с ним работать — сначала требуется прочитать кучку, зачастую увесистых, конфигов, чтобы разобраться — где что и как происходит и откуда растут ноги.

А хочется просто — взять и начать писать код, сразу. И просто писать тесты, легко запустить их, увидеть покрытие. И также получить финальную сборку.

Если вам хочется того же — то возможно вам будет интересно узнать о easymake.

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

Что такое HTML, CSS, JavaScript и Bootstrap фреймворк сложно объяснять человеку который далек от IT. А что если нужен сайт на бесплатном хостинге, без привязки к онлайн конструкту именно этого хостинга?!



Как думаете, реально научить девушку обновлять свой сайт на GitHub Pages к Международному женскому дню?! Расскажу как мне это удалось с помощью генератора сайта, который доступен на Github и написан на Java + FreeMarker, к тому же старался автоматизировать публикацию контента в git репозитарий.

Работая в многомодульном maven проекте, зачастую приходится вносить изменения в несколько связанных модулей одновременно. И если хочется собрать только задетые модули, то к сожалению maven не предоставляет ничего автоматического. Если чуть погуглить, то на stackoverflow можно найти простое однострочное решение:

mvn install -amd -pl $(svn st | colrm 1 8 | sed 's /.*  ' | xargs echo | sed 's- -,:-g' | sed 's ^ : ')

На этом можно было бы и закончить. Но мне хотелось большего — чего конкретнее и как я этого добивался под катом.

Apache Ant должен быть знаком каждому Java-программисту: это популярный инструмент сборки ПО (build tool), полностью написанный на Java. Ant использует сценарий, который является обычным XML-файлом. Несмотря на его Java-направленность, веб-разработчики тоже используют этот инструмент.

Мы пройдём пять простых шагов, чтобы начать использовать Ant:

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

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

Эта статья для тех, кто только начинает осваивать java.

В моей предыдущей статье было сказано, что maven сам скачает все указанные в pom.xml зависимости. А вот что будет, если он какую-нибудь зависимость не найдёт? В таком случае maven скажет, что зависимость не обнаружена и прервёт процесс сборки с ошибкой. Что делать в этом случае?

Мы продолжаем рассказывать о том, как внедряем практики и подходы DevOps. Например, недавно писали о создании собственного инструмента для проведения конкурентного анализа программных продуктов. Сегодня речь пойдет о том, как мы интегрировали систему TeamCity с внешним сервером отладочных символов.

С помощью VSTS можно автоматизировать развертывание и тестирование программного обеспечения в различных средах. Суть Continuous Integration заключается в выполнении частых автоматизированных сборок проекта для скорейшего выявления и решения интеграционных проблем. В частности CI позволяет автоматизировать регрессионное тестирование приложений.

В качестве ознакомления с возможностями VSTS предлагаю опубликовать и настроить Continuous Integration c Unit тестами простого UWP приложения.

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

Недавно я задумался, ковыряя очередную бесплатную систему сборки, «А нельзя ли взять и самому написать такую систему? Ведь это просто — взять ту же Ninja, прикрутить разделение на препроцессинг и компиляцию, да и передавать по сети файлы туда-сюда. Куда уж проще?»

Просто — не просто, как самому сделать подобную систему — расскажу под катом.

С переездом из SVN на GIT и gitlab (плюс переезд из Jenkins на Gitlab-CI, но его использование также упомянём), встал вопрос версионирования получаемых артефактов сборки приложения.

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

В итоге остановились на очень хорошем Gradle плагине github.com/nemerosa/versioning, о его использовании я и собираюсь рассказать.

История с удалением базы конечно затмила все остальные новости про ГитЛаб. Так что если вы пропустили релизный пост про изменения и новые функции в GitLab 8.16, ниже — его перевод:

Наша цель — сделать участие в разработке доступным для каждого. Для этого мы делаем инструментарий GitLab простым в использовании, настройке и обслуживании. В предыдущей версии GitLab мы реализовали простую настройку непрерывной интеграции (continuous integration, CI) и автоматическое развертывание (deploy) в Kubernetes. А в первом релизе нового года мы делаем следующий шаг к нашей цели.

Сейчас трудно представить разработку программного обеспечения без автоматизированных сборок проекта и тестирования. Для минимизации временных затрат на интеграцию изменений разработчиков в проект, существуют разные готовые решения. В данной статье я расскажу о замене сервера непрерывной интеграции CruiseControl.NET на Jenkins в команде разработчиков PVS-Studio. А также о том, что нас к этому побудило, какие цели мы преследовали и с какими проблемами столкнулись.

Спор между любителями CLI программ и приверженцами GUI берёт своё начало с появления самых первых ОС с графическим интерфейсом и продолжается до сих пор. Я никогда не имел ничего против хороших GUI приложений и с удовольствием пользовался Codekit с самой первой версии. Сейчас на дворе конец 2016 года и вышло мажорное обновление под номером 3.

Codekit — это расширяемый front-end сборщик «на стероидах» с графическим интерфейсом и возможностью навешивать скрипты по любому событию. Ближайшими «консольными» аналогами можно назвать Grunt и Gulp. GUI подразумевает невероятно простую конфигурацию — большинство настроек выставляются и меняются с помощью чекбоксов либо радиокнопок. Для всего остального есть мастеркард текстовые поля ввода, в которые вписываются те же параметры, что и в консольных программах.

Новое открытие TFS

Какая первая ассоциация возникает, когда слышишь словосочетание 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.

Как можно совместить некоторые достоинства динамических языков со строгой типизацией в обычном Java коде?