Публикую перевод моей статьи из блога ГитЛаба про то как начать использовать CI. Остальные переводы гитлабовских постов можно найти в блоге компании Softmart.

---

Представим на секунду, что вы не знаете ничего о концепции непрерывной интеграции (Continuous Integration — CI) и для чего она нужна. Или вы всё это забыли. В любом случае, начнем с основ.

Представьте, что вы работаете над проектом, в котором вся кодовая база состоит из двух текстовых файлов. Более того, очень важно, чтобы при конкатенации этих файлов в результате всегда получалась фраза "Hello world." Если это условие не выполняется, вся команда лишается месячной зарплаты. Да, все настолько серьезно.

В мае этого года вышел релиз ГитЛаба 8.8. Частью этого релиза был запуск встроенного Docker Container Registry. Ниже перевод майской статьи, посвященной этому.

Недавно нами был выпущен GitLab версии 8.8, в которой поддержка CI стала еще лучше. Теперь в GitLab можно строить конвейеры (pipelines) для визуализации сборок, тестов, развертывания и любых других этапов жизненного цикла вашего ПО. Сегодня мы представляем вам следующий этап: GitLab Container Registry .

GitLab Container Registry — это безопасный приватный реестр для образов (images) Docker, разработанный с помощью ПО с открытым кодом. GitLab Container Registry полностью интегрирован в GitLab.

Ключевыми особенностями GitLab являются непрерывность процесса разработки и взаимная интеграция различных элементов; эти принципы сохраняются и при работе с нашим реестром. Теперь при помощи GitLab Container Registry вы можете использовать ваши Docker-образы для GitLab CI, создавать специальные образы для отдельных тегов и веток, а также многое другое.

Стоит отметить, что GitLab Container Registry является первым реестром Docker, полностью интегрированным в систему управления Git-репозиториями. Кроме того, GitLab Container Registry не требует отдельной установки, так как является частью GitLab 8.8; c его помощью можно легко скачивать и загружать образы на GitLab CI. И еще он бесплатный.

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

Эта статья — перевод релизной статьи компании GitLab. Релизы выходят каждый месяц 22 числа.

Если вы пропустили предыдущие, вот ссылки: 8.10, 8.9, 8.8

---

В новом GitLab 8.11 столько всего интересного, что мы с трудом сдерживаем себя в рамках конструктивного повествования!

Итак, в новой версии появились:

• принципиально новый новый способ представления и работы с тикетами (issues);
• слеш-команды (/command) для работы с тикетами;
• возможность создавать шаблоны тикетов (в неограниченном количестве);
• онлайн-среда разработки;
• возможность разрешать конфликты мержа не выходя из GitLab;
• настройка прав на пуш в ветку для отдельных участников и групп (только в ЕЕ);
• … и много других фич, о которых мы тоже расскажем.
  

Уже традиционно к концу лета компания Serena обновляет версию своей платформы автоматизации бизнес-процессов Serena Business Manager (SBM). Новая версия содержит целый ряд знаковых нововведений, среди которых долгожданная поддержка REST Json API, новый тип форм с нативной поддержкой HTML5, универсальный клиент для мобильных устройств на iOS и Andriod, новые графические отчеты и многое другое. Но обо всем по порядку.

Всем привет, если вы не в курсе, мы начали публиковать переводы релизных статей ГитЛаба.
Если вы пропустили предыдущие, вот ссылки: 8.10, 8.9, 8.8

ГитЛаб выпускает релизы 22 числа каждого месяца.
Перевод поста про релиз 8.11 в работе, а пока представляю на ваш суд еще одну статью из блога ГитЛаба про различие терминологии у GitLab, GitHub и Bitbucket.

---

В зависимости от рабочих задач и потребностей клиентов разработчикам приходится использовать разные платформы управления репозиториями. Типичный разработчик участвует в каком-нибудь открытом проекте на GitHub, а на работе хостит проект одного клиента на GitLab, а другого — в Mercurial и на Bitbucket. Переключения между платформами осложняются тем, что в них одни и те же вещи могут называться совершенно по-разному. В этой статье мы поможем вам сопоставить различия и заодно объясним, почему мы выбрали именно такие названия.

Начиная с версии 8.4 в GitLab значительно улучшился процесс миграции репозиториев из GitHub. Теперь GitLab импортирует не только репозитории, но ещё и вики-страницы, тикеты и пулл-реквесты. При этом большинство сущностей не меняют своего названия. Например, специфические термины Git, такие как commit или push, везде одинаковы. Не меняются и такие общие термины, как users, webhooks и issues.

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

---

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

Всем привет. В этот раз задержка с переводом релизного поста получилась всего 10 дней, и это радует.
Переводом в этот раз занимался chebureque, за что ему большая благодарность!

Коротко: Увеличилась производительность, появилась защита веток от изменений с использованием масок, улучшили отображение диффов, добавили ручные действия в CI, массовую подписка на тикеты, улучшили поддержку Slack и добавили больше эмодзи.

Сам текст перевода:

---

Основная задача GitLab — позволить вам как можно быстрее пройти путь от идеи до готового к использованию продукта. Каждый наш релиз направлен на то, чтобы сделать этот путь еще проще, и версия 8.10 особенно преуспела в этом!

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

Наш июльский (MVP) — Winnie! Он очень сильно помог нам, исправляя баги и наводя порядок в нашем issue tracker-е.

Этот текст — перевод релизного поста из блога ГитЛаба. Перевод подготовлен компанией Softmart. Мы понимаем, что наш перевод далек от идеала, но считаем что даже такой перевод будут полезен многим, кто не владеет английским языком в достаточной мере. Иван Немытченко — nem — евангелист ГитЛаба по мере возможности редактирует текст. Если вы готовы предложить свою помощь в переводе статей, будем только рады. Спасибо за понимание!

С GitLab 8.9 комфортнее работать в больших сложных проектах. Блокировка файлов, назначение приоритетов меткам, гибкие настройки уровня вовлеченности в проект, и возможность запретить объединение веток(merge) до момента, пока билд не выполнится успешно. В GitLab CI теперь можно указывать среды(production, staging, и т.д.) и задавать срок хранения артефактов. Появились шаблоны настроек CI, так что начать им пользоваться теперь еще проще.

Персона месяца(MVP) — Руи Сантос. Он разработал возможность ограничивать обьединение веток до прохождения билда. Спасибо Руи!

С версии 8.8.0 добавилось 1761 коммитов, 1947 файла были изменены. Что конкретно изменилось — смотрите ниже.

Наш третий GitLab Саммит, прошел на этот раз в Остине, штат Техас, и мы выпустили наш 54-й релиз 22-го числа, несмотря на воскресенье. GitLab 8.8 готов к работе с улучшенным GitLab CI, повышенной производительностью, удобными шаблонами и многим другим.

Самой ценной персоной (MVP) этого месяца является Мэтт Оукс, за вклад в работу по скрытию текстового файла различий, по-умолчанию на ветке с .gitattributes.

Спасибо Мэтт!

Компания GitLab, разработчик одной из самых популярных web систем управления репозиториями GIT и управления разработкой программного обеспечения, заключила партнерское соглашение с компанией Softmart.



GitLab доступна пользователям в 2х версиях: Community Edition (CE), Enterprise Edition (EE). Каждую редакцию можно использовать либо локально в своей сети (self-hosted), либо на хостинге gitlab.com. Причем на бесплатном хостинге gillab.com развернута именно EE редакция, но без возможностей администрирования. Важной особенностью хостинга GitLab является отсутствие ограничений на количество подключаемых пользователей.

Редакция CE — бесплатная и потому наиболее популярная — позволяет интегрировать GitLab с системами сборки, организовать процесс просмотра кода (codereview), пользоваться встроенным модулем управления дефектами и задачами.

Редакция для серьезных профессионалов EE интересна прежде всего своими дополнительными функциональными возможностями, которых нет в других редакциях. Например, GIT HOOKS, позволяет анализировать Описание версии, находить в них предусмотренные макро команды и раскрывать их. Так реализована интеграция с Jira, если кому-то необходимо иметь обратную связь в внешней системой управления задачами.

Подробнее о версиях можно узнать на сайте GitLab.

Разрешите представить вам нашего нового партнера – канадскую компанию Tasktop – чьи программные продукты мы теперь официально представляем, внедряем и обслуживаем в России. Tasktop специализируется на интеграции систем, так или иначе связанных с разработкой программного обеспечения, например, сред разработки, систем контроля версий, систем автоматизированного тестирования, баг-трэкеров, систем автоматизации сервис-деска и т.д… Очень нишевой бизнес, но тем и интереснее. Везде, где с течением времени сложилась пестрая мозаика различных и безусловно нужных ИТ продуктов, и где есть необходимость их объединения в комплексное решение, могут пригодиться решения Tasktop.

Строго говоря, продуктов ровно 3 – Tasktop Sync, Tasktop Data и Tasktop Dev.

Компания Serena к празднику 8 марта выпустила обновление версии SBM 11.01, где исправила наиболее досадные дефекты, обнаружившиеся в связи с миграцией с Jboss на TomCat.

Продолжаем нашу серию заметок по статическому анализатору кода Kiuwan.

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

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

Друзья, доброго времени суток.

Честно говоря, уже устал поддерживать версии приложений на серверах и делать изменения в БД врукопашную. Использую свои скрипты установки — те же программы, за которыми тоже надо следить самому и править в разных обстоятельствах, типа добавления нового сервера или подготовки новой виртуалки тестировщикам. Захотелось посмотреть, какие есть цивилизованные решения для таких задач. Хочу поделиться первым опытом работы в среде автоматизации процесса развертывания софта – Serena Deployment Automation (SDA) — продукт бесплатен при условии использования на не более 5 серверах.

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

За определениями термина «качество программного обеспечения» не грех обратиться к стандартам. Несколько определений из разных стандартов удобно приведены на одной странице wiki. И что же?! В фокусе способности программы удовлетворять потребностям Заказчика.

Пройдясь поиском по Хабрахабру, удалось обнаружить не так уж и много информации, посвященной, надо сказать, не очень распространённому языку BPEL (Business Process Execution Language). Если говорить в общем, то BPEL – это язык, основанный на формате XML, который позволяет описывать логику бизнес-процессов через использование веб-служб.

Реализаций движков, позволяющих создавать процессы с использованием этого языка, мне известно не так уж и много. В частности, можно упомянуть Oracle BPEL Process Manager и продукт, о котором пойдет речь дальше – Serena Business Manager (SBM). SBM позволяет быстро создавать web-приложения, автоматизирующие какой-нибудь процесс. В модели процесса (workflow) предусмотрена возможность в момент изменения состояния вызвать внешнюю web службу. А если нужно реализовать какую-нибудь логику и одного вызова недостаточно? Вот тут и пригодится процедура, написанная на языке BPEL и исполняемая средствами той же платформы BPM.

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