В своей статье "Использование GitHub в обучении студентов" я кратко коснулся темы использования GitHub'а именно как инструмента для обучения, а не как темы в обучении. Сейчас хочу попробовать привести примеры нескольких кейсов.
Начну с относительно простого варианта, а в следующих статьях расскажу про другие варианты.
В своей преподавательской практике использую GitHub...
Но для начала давайте представлюсь. Зовут меня Старинин Андрей. И я преподаю программирование, хотя по первому образованию я биолог.
Открываю VS Code и начинаю набирать статью с самого начала. Но вот незадача — формат маркдауна не совсем совместим с имеющимся форматом Хабра. Получается выхода нет и придётся возвращаться к встроенному редактору Хабра;
Или не придется?
В голову пришла идея написать утилиту, которая конвертирует разные форматы маркдаунов друг в друга, например, из формата GitHub в формат Habr;
Такую программу я в итоге и разработал. Теперь не надо копировать статьи в редактор Хабра, чтобы посмотреть как она выглядит, можно продолжать писать в любимом VS Code;
Хотя я и использую множество плагинов VS Code, но мысли о неэффективном процессе написания статей не исчезли. Раз уж я набираю текст в VS Code, то почему бы сразу не делать коммиты контента в гит-репозиторий?
Это дало бы немало новых возможностей, которыми пользуются программисты: версионирование, бекапы на локальные носители или веб-сервисы, правки от редакторов и пользователей. А еще можно внедрить CD/CI;
В итоге, я написал небольшой гайд для разработчиков, как писать техническую документацию в редакторах, используя мою утилиту. Саму утилиту можно посмотреть в моём репозитории на GitHub;
Helm, как и Docker стал де-факто стандартом в индустрии. Тоже самое и с Kubernetes (52% доля в нише). И новость, что Docker is deprecated вызвало волну обсуждений в сообществе. Настолько все привыкли к Docker.
Команда GitLab стремится к повышению производительности и степени удовлетворённости разработчиков. Релиз 13.6 содержит все необходимые ингредиенты, которые помогут вам достичь этого и, возможно, чего-то ещё! Мы надеемся, что вам пригодятся основные фичи релиза, а также ещё более 60 новых фич и улучшений, добавленных в этом релизе.
Управление миграциями баз данных для нескольких сред и команд может быть достаточно сложной задачей. В этой статье описывается, как сочетание Git, контейнеров и клонов баз данных используется для реализации доставки в среды разработки, тестирования и стейджинга за считанные секунды.
Хотя Git и так часто используется в сочетании с контейнерами баз данных, описанный здесь подход все же вводит два новых элемента. Вместо того, чтобы воспроизводить базы данных из бекапов или создавать из источника данных, мы клонируем идентичные безопасные среды производственных баз данных и доставляем их в течении секунд. Клоны баз данных доступны для записи и позволяют легко внедрять маскирование данных и синтетические тестовые данные. Второй элемент - это файл манифеста сценариев, используемый при создании и применении персонализированных сценариев миграции.
Разработчик может работать с клоном производственной базы данных в функциональной ветке - сценарии для этой ветки применяются автоматически. В то же время команда тестирования может работать в релизной ветке с идентичным клоном производственной базы данных - для нее применяется набор релизных сценариев. На каком-нибудь конвейерном стейдже можно протестировать откат релизной ветки с третьим идентичным безопасным клоном производственной базы данных, благодаря автоматическому применению сценариев обновления и отката.
Эта статья берет за основу SQL Server, но эти методы также поддерживаются Postgres и MySQL.
Вышел релиз GitLab 13.5 со сканированием безопасности мобильных приложений, вики-страницами групп, общим реестром пакетов и многими другими классными фичами!
refspec во время git fetch ускоряет шаг клонирования в 100 раз. 
Эксперт OTUS - Владимир Дроздецкий приглашает всех желающих на бесплатный вебинар, в рамках которого он подробно расскажет о программе курса "DevOps практики и инструменты" и ответит на интересующие вопросы. А прямо сейчас, по устоявшейся традиции, делимся с вами интересным переводом.
Недавно я общался с разработчиками из Humanitec (это Continuous Delivery-платформа для Kubernetes). Humanitec интересен тем, что вопреки современным тенденциям, он не основан на GitOps.
Лично я большой фанат GitOps, потому что он позволяет строить CI/CD без сложных инструментов с использованием только Git и декларативного описания конфигураций. Но несмотря на то, что я недавно написал статью "11 Reasons for Adopting GitOps" (11 причин для внедрения GitOps), в своей практике я неоднократно сталкиваюсь с ограничениями этого подхода. Беседа с ребятами из Humanitec побудила меня написать об этом негативном опыте для того, чтобы предоставить вам более объективную картину GitOps и поговорить об альтернативных подходах.
Всем привет! Меня зовут Станислав Лукьянов. Я работаю в компании GridGain. Сегодня я хотел поговорить о том, как мы поддерживаем старые версии в Git.
До 2020 года я работал конструктором (разрабатывал электронику и электрику). Сейчас я сменил сферу деятельности, но считаю важным поднять вопрос, который возник в свое время пока он совсем не выветрился из головы. В статье затронута важность разработки стандартов в команде hardware разработчиков, а также приведен пример одного из стандартов для ведения репозитория для сборку.
/target // скрипты для сборки ядер
/toolchain // скрипты для сборки gcc, musl и прочих инструментов сборки
/feeds // дополнительные репозитории с приложениями
/package // скрипты для сборки приложений
...
В GitLab мы всегда думаем о том, как помочь пользователям снизить риски, повысить эффективность и скорость поставки на вашей любимой платформе. В этом месяце мы добавили немало полезных новшеств, которые расширяют возможности безопасности, снижают количество уязвимостей, повышают эффективность, упрощают работу с GitLab и помогают вашей команде поставлять фичи ещё быстрее. Мы надеемся, что вам пригодятся основные фичи релиза, а также 53 другие новые фичи, добавленные в этом релизе.