Как стать автором
Обновить
59
0
Иван Немытченко @nem

Smartprogrammer.ru

Отправить сообщение

Для чего программисту Continuous Integration и с чего начинать

Время на прочтение8 мин
Количество просмотров52K
Представьте что в Роскосмосе решили собрать новую ракету не имея при этом чертежей и четкого понимания как ракета должна быть устроена. Отдельный завод занимается корпусом ракеты, отдельный выпускает двигатели, еще один — сопла. Главный менеджер Роскосмоса сказал что он доверяет профессионалам, и мастерски сделегировал всю работу заводам.



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

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

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

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

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

В 1991 году Гради Буч, видимо, устал от такого безобразия, и предложил делать сборку всего проекта каждый день, чтобы выяснять несовместимости не в день релиза, а пораньше — и назвал этот подход Continuous Integration.
Читать дальше →
Всего голосов 58: ↑52 и ↓6+46
Комментарии56

Вышел GitLab 8.16: Поддержка Google Container Engine, встроенный Prometheus + тайм-трекинг в CE

Время на прочтение8 мин
Количество просмотров8.9K

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


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


Всего голосов 15: ↑14 и ↓1+13
Комментарии8

Вышел GitLab 8.15

Время на прочтение8 мин
Количество просмотров15K

В последнем релизе уходящего года мы завершаем наш Мастер-план и хотим показать вам кое-что интересное из того, над чем мы работали.



В 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 тоже получил в подарок много новых фич.


Всего голосов 29: ↑28 и ↓1+27
Комментарии13

Вышел GitLab 8.14

Время на прочтение7 мин
Количество просмотров10K

Представьте, что вы делаете ревью кода новой фичи. Помимо качества ее кода вам также интересно, как она будет выглядеть и работать в вашем продукте и насколько удобно будет ее использовать. Раньше вам пришлось бы прервать процесс разработки на собственной рабочей машине, сделать checkout на проверяемую ветку, провести нужные миграции БД и запустить всю рабочую среду (development environment), необходимую для приложения. Теперь вам будет достаточно зайти в мерж-реквест этой ветки на GitLab. Там будет ссылка на уже работающее приложение, развернутое в отдельной среде.


Наконец, ревью завершено, и вы даете коллеге обратную связь в чате. Вместо того, чтобы решать, кто из вас пойдет заводить новую задачу в трекере, вы можете создать задачу и оценить время на ее разработку, не выходя из чата. Аналитика цикла разработки (cycle analytics) сразу учтет данную оценку и будет показывать вам весь путь задачи до выпуска на production, сообщая о возможных узких местах.


Все это и многое другое возможно в новой версии GitLab 8.14. В ней появился учет рабочего времени, приложения для ревью (Review Apps), команды чата (chat commands) и новые возможности аналитики цикла разработки.


Читать дальше →
Всего голосов 26: ↑25 и ↓1+24
Комментарии4

GitLab Flow

Время на прочтение15 мин
Количество просмотров106K

Это перевод достаточно важной статьи про GitLab Flow, альтернативе Git flow и GitHub flow. Статья была написана в 2014, так что скриншоты успели устареть. Тем не менее сама статья более чем актуальна:




Ветвление и слияние веток в git устроено гораздо проще, чем в более ранних системах контроля версий, таких как SVN. Поэтому есть много способов организации командной работы над кодом, и большинство из них достаточно хороши. По крайней мере, они дают много преимуществ по сравнению с тем, что было до git. Но сам по себе git — не серебряная пуля, и во многих командах организация рабочего процесса с git имеет ряд проблем:


  • Не описан точным образом весь рабочий процесс,
  • Вносится ненужная сложность,
  • Нет связи с трекером задач (issue tracker).

Мы хотим представить вам GitLab flow — чётко определённый набор практик, решающий эти проблемы. Он объединяет в одну систему:



Читать дальше →
Всего голосов 29: ↑29 и ↓0+29
Комментарии21

Релиз GitLab 8.13

Время на прочтение9 мин
Количество просмотров8.9K

Мы путешествуем по миру и очень рады встречам с нашими пользователями.


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


Теперь можно создавать несколько досок задач (issue boards), а находясь на странице доски — быстро заводить новые задачи. Жизнь мерж-конфликтов стала ещё тяжелее и скоротечнее, потому что теперь их можно разрешать непосредственно в GitLab. Улучшенная система Cycle Analytics позволяет ещё проще следить за тем, какая версия кода выполняется в каждом из окружений (environments), а также предоставляет вам моментальную обратную связь.


Званием MVP этого месяца награждается Марк Зигфридт (Marc Siegfriedt) за его вклад в создание точки входа (endpoint) API для коммита нескольких файлов сразу. Марк проявил терпение и упорство в работе над этим сложным мерж-реквестом. Спасибо, Марк!


Читать дальше →
Всего голосов 18: ↑17 и ↓1+16
Комментарии5

GitLab о политике управления проектами open source

Время на прочтение5 мин
Количество просмотров8K

Некоторые скептически высказываются насчет ГитЛаба — мол вот вы перестанете поддерживать бесплатный Community Edition(CE), и что мы будем делать? Не перестанем. Публикуем для вас перевод статьи на эту тему.




Недавно мы зафиксировали нашу политику в отношении поддержки ПО с открытым кодом (open source) и нашу преданность этому методу разработки. Коротко нашу политику можно описать так: нужно принимать решения в интересах проекта, при этом не забывая о бизнесе, который этот проект поддерживает. В этой статье я хочу поделиться с вами соображениями о некоторых правилах в нашей политике.


Читать дальше →
Всего голосов 29: ↑28 и ↓1+27
Комментарии3

Вышел GitLab 8.12

Время на прочтение11 мин
Количество просмотров15K

Вне зависимости от масштаба вашего проекта, ваш инструментарий должен:


а. быть удобным в работе
б. давать полезную обратную связь.

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


Читать дальше →
Всего голосов 30: ↑30 и ↓0+30
Комментарии19

GitLab CI: Учимся деплоить

Время на прочтение9 мин
Количество просмотров125K

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


Чтобы не привязываться к какой-либо конкретной технологии, предположим, что ваше приложение является простым набором HTML-файлов, никакого выполнения кода на сервере, никакой компиляции JS assets. Деплоить будем на Amazon S3.


У автора нет цели дать рецепты для конкретной технологии в этой статье. Наоборот, примеры кода максимально примитивны, чтобы слишком на них не зацикливаться. Смысл в том чтобы вы посмотрели на фичи и принципы работы GitLab CI в действии, а потом применили их для вашей технологии.



Читать дальше →
Всего голосов 26: ↑26 и ↓0+26
Комментарии4

Введение в GitLab CI

Время на прочтение6 мин
Количество просмотров240K

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




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


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


Hello wolrd


Читать дальше →
Всего голосов 45: ↑44 и ↓1+43
Комментарии21

GitLab Container Registry

Время на прочтение6 мин
Количество просмотров64K

В мае этого года вышел релиз ГитЛаба 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, обратитесь к документации для администратора.


Читать дальше →
Всего голосов 24: ↑24 и ↓0+24
Комментарии26

GitLab 8.11: канбан-доска и разрешение конфликтов одним кликом

Время на прочтение11 мин
Количество просмотров38K

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


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




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


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


  • принципиально новый новый способ представления и работы с тикетами (issues);
  • слеш-команды (/command) для работы с тикетами;
  • возможность создавать шаблоны тикетов (в неограниченном количестве);
  • онлайн-среда разработки;
  • возможность разрешать конфликты мержа не выходя из GitLab;
  • настройка прав на пуш в ветку для отдельных участников и групп (только в ЕЕ);
  • … и много других фич, о которых мы тоже расскажем.
Читать дальше →
Всего голосов 35: ↑33 и ↓2+31
Комментарии33

Сопоставляем неоднозначные термины в GitLab, GitHub и Bitbucket

Время на прочтение3 мин
Количество просмотров22K

Всем привет, если вы не в курсе, мы начали публиковать переводы релизных статей ГитЛаба.
Если вы пропустили предыдущие, вот ссылки: 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.


Читать дальше →
Всего голосов 21: ↑21 и ↓0+21
Комментарии23

8 советов для более эффективной работы с Git

Время на прочтение3 мин
Количество просмотров46K

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




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


Читать дальше →
Всего голосов 50: ↑43 и ↓7+36
Комментарии25

Вышел GitLab 8.10

Время на прочтение10 мин
Количество просмотров14K

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


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


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




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


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


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


Читать дальше →
Всего голосов 18: ↑17 и ↓1+16
Комментарии23

Две причины выкинуть клиент вашего облачного хранилища на свалку

Время на прочтение3 мин
Количество просмотров18K

У вас 100% есть Dropbox. Или “Яндекс.Диск”. Или даже “Облако Mail.ru”.
Все они хранят в облаке то, что уже и так есть у вас на компе.


Это хорошо для:


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

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



Под катом две неудачные попытки и одна супер-удачная.

Читать дальше →
Всего голосов 27: ↑17 и ↓10+7
Комментарии83

Информация

В рейтинге
Не участвует
Откуда
Сербия
Зарегистрирован
Активность