Git *

Содержание

• Основные различия
• Reproducibility crisis
• Система контроля версий
• Data Version Control
• Полезные ссылки

Введение

Несмотря на всю пользу DVC, об этом инструменте знает катастрофически мало разработчиков. Поэтому, думаю, не лишним будет для начала вас познакомить. DVC – это open-source система контроля версий данных, которая отлично подходит для машинного обучения. И основное отличие DVC от Git’a в том, что он: во-первых, имеет более широкий и удобный инструментарий для ML-проектов; во-вторых, создан для контроля версий данных, а не кода. И по большей части здесь их основные различия заканчиваются. А далее я постараюсь описать, чем же так хорош DVC, и почему Git'а не достаточно для ML.

Всем привет!

Закончилась осень, зима вступила в свои законные права, листья уже давно опали и перепутанные ветви кустарников наталкивают меня на мысли о моём рабочем Git репозитории… Но вот начался новый проект: новая команда, чистый, как только что выпавший снег, репозиторий. "Тут все будет по другому" - думаю я и начинаю "гуглить" про Trunk Based Development.

Если у вас никак не получается поддерживать git flow, вам надоели кучи этих непонятных веток и правил для них, если в вашем проекте появляются ветки вида "develop/ivanov", то добро пожаловать в под кат! Там я пробегусь по основным моментам Trunk Based Development и расскажу о том, как реализовать такой подход, используя Spring Boot.

 git show deadbeef 

 git log -p Page.php 

В своей статье "Использование 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 со сканированием безопасности мобильных приложений, вики-страницами групп, общим реестром пакетов и многими другими классными фичами!

Эксперт OTUS - Владимир Дроздецкий приглашает всех желающих на бесплатный вебинар, в рамках которого он подробно расскажет о программе курса "DevOps практики и инструменты" и ответит на интересующие вопросы. А прямо сейчас, по устоявшейся традиции, делимся с вами интересным переводом.

Недавно я общался с разработчиками из Humanitec (это Continuous Delivery-платформа для Kubernetes). Humanitec интересен тем, что вопреки современным тенденциям, он не основан на GitOps.

Лично я большой фанат GitOps, потому что он позволяет строить CI/CD без сложных инструментов с использованием только Git и декларативного описания конфигураций. Но несмотря на то, что я недавно написал статью "11 Reasons for Adopting GitOps" (11 причин для внедрения GitOps), в своей практике я неоднократно сталкиваюсь с ограничениями этого подхода. Беседа с ребятами из Humanitec побудила меня написать об этом негативном опыте для того, чтобы предоставить вам более объективную картину GitOps и поговорить об альтернативных подходах.

Всем привет! Меня зовут Станислав Лукьянов. Я работаю в компании GridGain. Сегодня я хотел поговорить о том, как мы поддерживаем старые версии в Git.