Здравствуйте, друзья! Появление популярного менеджера зависимостей в PHP — является одним из важнейших событий в жизни PHP-сообщества. Composer разделил время на "до" — когда наши самописные библиотеки лежали в zip-архивах или просто разбросаны по папкам и копировались "ручками", лишь в единичных случаях, использовался git или PEAR, и "после" — когда мы начали использовать composer. Но что делать если вы работаете с определенной CMS, а она не "знает" что такое composer?
Вышел GitLab 11.4 с ревью мерж-реквестов и подключаемыми фичами
17 мин
Перевод
Мы рады представить новый релиз GitLab 11.4 с долгожданными обновлениями, призванными помочь командам работать эффективнее. Большинство команд, применяющих DevOps, стремятся к сокращению времени цикла поставки. Поэтому разработчики всегда рады улучшениям, которые уменьшат количество работы и потери во времени, так как за счет этого ускоряется поставка продукта и повышаются бизнес-показатели.
Вышел GitLab 11.3 с репозиторием Maven и защищенными окружениями
12 мин
Перевод
С новым релизом GitLab 11.3 мы рады представить вам поддержку репозиториев Maven, владельцев кода (Code Owners), защищенные окружения и прогнозы для эпиков. Все это поможет автоматизировать управление окружениями и кодом, что позволит разработчикам на Java быть еще эффективнее.
Вышел GitLab 11.2: предпросмотр в Web IDE и импорт проектов под Android
15 мин
Перевод
Мы с воодушевлением представляем вам новые возможности версии 11.2, которые помогут вам быстрее стартовать и выпускать новые версии. В этот раз мы запускаем улучшения для Web IDE, поддержку импорта манифестов Андроид-проектов и настраиваемые шаблоны проектов.
Правило 10:1 в программировании и писательстве
7 мин
Перевод
В этой статье автор анализирует количество времени, которое тратится на написание книг или программного кода, и приходит к интересной закономерности. Ее можно применять для планирования сроков работы над проектами.
У написания прозы и кода есть много общего. Но самое заметное сходство, вероятно, заключается в том, что ни писатели, ни программисты не могут закончить свою работу вовремя. Писатели славятся отъявленной привычкой срывать сроки. Программисты заслужили репутацию людей, чьи результаты всегда серьезно отличаются от первоначальных расчетов. Возникает вопрос: почему?
Сегодня у меня появилась идея, как можно на него ответить. И мои находки меня поразили.
Обе свои книги, Привет, стартап и Terraform: запускаем и работаем, я написал в среде для создания книг Atlas, которая предусматривает управление всем контентом с помощью Git. Это означает, что каждая строчка текста, каждая правка и каждое изменение были зафиксированы в коммит-логе Git.
Проверим, сколько же усилий было затрачено на написание двух книг.
Привет, стартап
Начнем с моей первой книги Привет, стартап. В ней 602 страницы и примерно 190 тыс. слов. Я запустил
Закон Хофштадтера: Любое дело всегда длится дольше, чем ожидается, даже если учесть закон Хофштадтера.
— Дуглас Хофштадтер, Гёдель, Эшер, Бах
У написания прозы и кода есть много общего. Но самое заметное сходство, вероятно, заключается в том, что ни писатели, ни программисты не могут закончить свою работу вовремя. Писатели славятся отъявленной привычкой срывать сроки. Программисты заслужили репутацию людей, чьи результаты всегда серьезно отличаются от первоначальных расчетов. Возникает вопрос: почему?
Сегодня у меня появилась идея, как можно на него ответить. И мои находки меня поразили.
Изучая свои книги
Обе свои книги, Привет, стартап и Terraform: запускаем и работаем, я написал в среде для создания книг Atlas, которая предусматривает управление всем контентом с помощью Git. Это означает, что каждая строчка текста, каждая правка и каждое изменение были зафиксированы в коммит-логе Git.
Проверим, сколько же усилий было затрачено на написание двух книг.
Привет, стартап
Начнем с моей первой книги Привет, стартап. В ней 602 страницы и примерно 190 тыс. слов. Я запустил
cloc в git-репозитории Hello, Startup и получил следующие результаты
Эволюция одного стартапа. Agile от Яйцелова до Chiken Invaders
7 мин
Как перестать ловить яйца в спешке, попутно роняя дедлайны? Какой тулчейн выбрать, чтоб уничтожать по несколько тасков за раз? Все это раскроем в нашей статье.
Продвинутое использование Гита или как выйти на пенсию на полгода раньше?
11 мин
Туториал
Не знаю, на каком языке программирования вы пишете, но уверен, что используете Гит при разработке. Инструментов для сопровождения разработки становится всё больше, но даже самый маленький тестовый проект, я неизменно начинаю с команды git init. А в течение рабочего дня набираю в среднем ещё 80 команд, обращаясь к этой системе контроля версий.
Я потратил кучу нервов, когда стал переучиваться на десятипальцевый метод печати. В итоге это стало самым правильным решением по улучшению личного рабочего процесса. В числе следующих по важности оптимизаций стоит углубленное освоение Гита.
На Хабр написано много статей о Гите, но они не уходят дальше официальной документации, а упрощать работу авторы предлагают самописными костылями. Я уверен, что изучать Гит нужно на конкретных примерах задач, а повышать эффективность работы с ним – стандартизированными средствами.
Кому будет полезна эта статья?
Вы уже освоили джентльменский набор Гита и готовы двигаться дальше? Существует 2 пути:
- Освоить сокращённые команды – алиасы. Они почти всегда составлены мнемонически и легко запоминаются. Забыть оригиналы команд проблематично, я легко их набираю, когда это требуется. Плюс не сбиваюсь с мысли, проверяя что-то в Гите в процессе написания кода.
- Узнать о дополнительных флагах к командам, а также их объединении между собой. Я понимаю, что кто-то ненавидит сокращения. Для вас тоже есть интересный материал в статье – как повысить полезность и удобство вывода команд, а также как решать не самые тривиальные, но часто встречающиеся на практике задачи.
Посвятите описанным в статье экспериментам пару часов сегодня, и сэкономьте по приблизительным расчётам полгода рабочей жизни.
Добро пожаловать под кат!
GitLab для Continuous Delivery проекта на технологиях InterSystems: Контейнеры
16 мин
Туториал
Эта статья — продолжение статьи про организацию процессов Continuous Integration / Continuous Delivery, автоматизирующих сборку, тестирование и доставку приложений применимо к решениям на платформе InterSystems.
Рассмотрим такие темы как:
- Контейнеры 101
- Контейнеры на разных этапах цикла разработки ПО
- Continuous Delivery с контейнерами
Git happens! 6 типичных ошибок Git и как их исправить
5 мин
Перевод
Прим. перев.: На днях в блоге для инженеров любимого нами проекта GitLab появилась небольшая, но весьма полезная заметка с инструкциями, которые помогают сохранить время и нервы в случае различных проблем, случающихся по мере работы с Git. Вряд ли они будут новы для опытных пользователей, но обязательно найдутся и те, кому они пригодятся. А в конец этого материала мы добавили небольшой бонус от себя. Хорошей всем пятницы!
Все мы делаем ошибки, особенно при работе с такими сложными системами, как Git. Но помните: Git happens!
Вышел GitLab 11.1: Панель управления безопасностью и улучшенный поиск
12 мин
Перевод
В GitLab 11.1 мы улучшили отображение безопасности за счёт панелей, усовершенствовали поиск по коду для своевременного получения нужной информации, внесли изменения в UX и многое другое.
Как следует писать комментарии к коммитам
11 мин
Перевод
Предисловие от переводчика
На протяжении многих лет разработки ПО, будучи участником многих команд, работая с разными хорошими и опытными людьми, я часто наблюдал (да и чего греха таить, до определенного момента — создавал) одну и ту же проблему — тотальный бардак в репозитории. Каждый писал комментарии к коммитам в своем стиле (и хорошо, если постоянно в одном); половина комментариев была бесполезна (из разряда "это мост"), половина оставшейся половины — едва понятна.
И вот в один прекрасный момент я увидел данную статью, до перевода которой у меня наконец дошли руки. Всего 7 простых и коротких правил, и — о чудо — смотреть на историю коммитов стало не только полезно, но и приятно. Ничего революционного, все довольно очевидно, но сформулировано и резюмировано просто отлично.
Вышел GitLab 11.0: Auto DevOps и управление лицензиями
18 мин
Перевод
Создание качественного ПО — непростой процесс. Во-первых, нужно решать бизнес-проблемы и писать качественный код. Однако, на этом сложности не заканчиваются: нужно еще удостовериться в том, что ваш код работает быстро, безопасно и надежно. Работа с кодом — это конвейер из множества этапов, таких как сборка, интеграция, тестирование, обеспечение безопасности, ревью, настройка и развертывание. На выполнение всех этих действий уходит много времени и сил.
Вышел GitLab 10.8: зеркалирование пушей в открытом доступе и инкрементное развертывание
12 мин
Перевод
Мы с радостью представляем вам новую версию GitLab со множеством нововведений и улучшений! В данном релизе мы улучшили автоматизацию релизов, вывели в общий доступ ранее платную функциональность, ускорили исправление уязвимостей безопасности и многое другое.
Ближайшие события
15 советов по работе с Github
8 мин
Туториал
Перевод
Я 10 лет разрабатываю ПО, участвовал в нескольких open source-проектах и в многочисленных не-open source-проектах, работал в больших и малых командах, и везде мы использовали Github в качестве репозитория версионирования.
За это время я перепробовал разные рабочие процессы, и хочу поделиться советами, как построить эффективный и прагматичный рабочий процесс по созданию и сопровождению качественного ПО, который можно применять в любом проекте.
Вышел GitLab 10.7: Web IDE в открытом доступе и отчеты SAST для Go и C/C++
14 мин
Перевод
Добавление новой функциональности, ревью изменений и развертывание кода — все это стандартные рабочие процессы, с которыми ежедневно сталкиваются разработчики. С выходом данного релиза мы упрощаем их выполнение с помощью нашего Web IDE, более гибких конвейеров, дополнительного тестирования безопасности и многого другого.
GitLab для Continuous Delivery проекта на технологиях InterSystems
15 мин
Туториал
В данной статье хотелось бы рассказать про организацию процессов Continuous Integration / Continuous Delivery, автоматизирующих сборку, тестирование и доставку приложений на платформах InterSystems.
Рассмотрим такие темы как:
- Git 101
- Методологии разработки (Git flow)
- GitHub flow
- GitLab flow
- GitLab
- GitLab CI
Почему SQLite не использует Git
6 мин
Перевод
Содержание
1. Введение
SQLite не использует Git. Вместо этого у нас работает система управления версиями Fossil, специально разработанная и написанная для поддержки SQLite.
Люди иногда спрашивают, почему SQLite не использует Git, как все остальные. В статье мы попробуем ответить на этот вопрос. Кроме того, в третьем разделе приводятся советы для пользователей Git, как легко получить доступ к исходному коду SQLite.
Для чего программисту Continuous Integration и с чего начинать
8 мин
Представьте что в Роскосмосе решили собрать новую ракету не имея при этом чертежей и четкого понимания как ракета должна быть устроена. Отдельный завод занимается корпусом ракеты, отдельный выпускает двигатели, еще один — сопла. Главный менеджер Роскосмоса сказал что он доверяет профессионалам, и мастерски сделегировал всю работу заводам.
Через год все составные части доставляются в главный сборочный цех, и выясняется, что двигатель не входит в корпус, а сопла начинают плавиться даже при тестовых запусках двигателя.
Чтобы такой фигни не случалось, в реальных проектах всегда есть этап планирования и проектирования, на котором фиксируются спецификации того как части будут взаимодействовать между собой и какими характеристиками ни должны обладать.
При разработке ПО мы не можем себе позволить долгий этап проектирования, т.к. за это время потеряется бизнес-ценность того что мы пытаемся разработать — нас тупо обойдут конкуренты.
Поэтому команды, разрабатывающие составные части программы(модули) зачастую вынуждены работать не до конца понимая как их модуль будет взаимодействовать с остальными частями.
Как и в случае с ракетой, при попытке выпустить новый релиз приложения, разрабатываемого по частям несколькими командами, может выясниться что какие-то из модулей не совместимы.
В 1991 году Гради Буч, видимо, устал от такого безобразия, и предложил делать сборку всего проекта каждый день, чтобы выяснять несовместимости не в день релиза, а пораньше — и назвал этот подход Continuous Integration.
Через год все составные части доставляются в главный сборочный цех, и выясняется, что двигатель не входит в корпус, а сопла начинают плавиться даже при тестовых запусках двигателя.
Чтобы такой фигни не случалось, в реальных проектах всегда есть этап планирования и проектирования, на котором фиксируются спецификации того как части будут взаимодействовать между собой и какими характеристиками ни должны обладать.
При разработке ПО мы не можем себе позволить долгий этап проектирования, т.к. за это время потеряется бизнес-ценность того что мы пытаемся разработать — нас тупо обойдут конкуренты.
Поэтому команды, разрабатывающие составные части программы(модули) зачастую вынуждены работать не до конца понимая как их модуль будет взаимодействовать с остальными частями.
Как и в случае с ракетой, при попытке выпустить новый релиз приложения, разрабатываемого по частям несколькими командами, может выясниться что какие-то из модулей не совместимы.
В 1991 году Гради Буч, видимо, устал от такого безобразия, и предложил делать сборку всего проекта каждый день, чтобы выяснять несовместимости не в день релиза, а пораньше — и назвал этот подход Continuous Integration.
Вышел GitLab 10.6: CI/CD для GitHub и углубленная интеграция с Kubernetes
11 мин
Перевод
Непрерывная интеграция, поставка и развертывание являются основополагающими принципами DevOps. В GitLab включена функциональность CI/CD, которая пришлась по душе как разработчикам и аналитикам, так и компаниям в целом.
Считаем серверы, рабочие станции, лицензии, разливаем обновления и автоматизируем IT-процессы
5 мин
На одном из мест работы я как-то столкнулся с ситуацией, когда один коллега был пойман на свинчивании планок памяти из своей рабочей станции. Тот не стал отнекиваться и сразу сказал, что брал домой потестировать и собирался вернуть. Но все кагбэ поняли. Не знаю как у вас, но на моей памяти такое было единственный раз. Возможно, такое случается сплошь и рядом.
Случай всплыл в памяти по ходу написания статьи. Уже давно собирался рассказать о специальной софтине для сбора всяких инвентаризационных штук с железок — KACE. С ней я знаком как минимум пару лет и не раз приходилось поработать на практике. Сейчас сошлись звезды, мысли собрались в кучу и, наконец, пишу как эта штука может быть полезна для контор от нескольких рабочих станций до многотысячных парков ИТ-оборудования. Вещь простая как валенок и функциональная как микроволновка с грилем и конвекцией, а развернутой статьи на Хабре про нее до сих пор не было.
Случай всплыл в памяти по ходу написания статьи. Уже давно собирался рассказать о специальной софтине для сбора всяких инвентаризационных штук с железок — KACE. С ней я знаком как минимум пару лет и не раз приходилось поработать на практике. Сейчас сошлись звезды, мысли собрались в кучу и, наконец, пишу как эта штука может быть полезна для контор от нескольких рабочих станций до многотысячных парков ИТ-оборудования. Вещь простая как валенок и функциональная как микроволновка с грилем и конвекцией, а развернутой статьи на Хабре про нее до сих пор не было.