Git *

TLDR: Сделал набор скриптов автоматизации миграции Bitbucket репозиториев с Mercurial на Git.

В один непрекрасный день мой любимый хостинг репозиториев Bitbucket объявил о скором прекращении поддержки репозиториев Mercurial в пользу Git, после чего все Mercurial репозитории будут удалены.

Вышел релиз GitLab 12.7 — с улучшениями, которые помогут вашим командам и конвейерам (в русской локализации GitLab «сборочные линии») стать более эффективными и результативными. Настройка автоматизации и конвейеров — основа продуктивной работы команд DevOps, и в 12.7 мы предлагаем множество нововведений, которые сделают вашу работу быстрее и эффективнее. Например, конвейеры Parent-Child, группы ресурсов конвейера и бета-версию общих обработчиков заданий (shared runner) для Windows на GitLab.com.

Позвольте мне рассказать вам историю. Жили-были два разработчика: Сэм и Боб. Они вместе работали над проектом, в котором была база данных. Когда разработчик хотел внести в неё изменения, он обязан был создать файл stepNNN.sql, где NNN — некоторое число. Чтобы избежать конфликтов этих чисел между различными разработчиками, они использовали простой Web-сервис. Каждый разработчик прежде чем начать писать SQL-файл должен был зайти на этот сервис и зарезервировать за собой новое число для step-файла.

В этот раз Сэму и Бобу обоим нужно было внести изменения в базу данных. Сэм послушно отправился на сервис и зарезервировал за собой число 333. А Боб забыл сделать это. Он просто использовал 333 для своего step-файла. Так случилось, что в этот раз Боб первым залил свои изменения в систему контроля версий. Когда Сэм был готов залиться, он обнаружил, что файл step333.sql уже существует. Он связался с Бобом, объяснил ему, что номер 333 был зарезервирован за ним и попросил исправить конфликт. Но Боб ответил:

— Чувак, мой код уже в 'master'е, куча разработчиков уже используют его. К тому же он уже выкачен на production. Так что просто исправь там у себя всё, что нужно.

Надеюсь, вы заметили, что произошло. Наказанным оказался человек, который следовал всем правилам. Сэму пришлось менять свои файлы, править свою локальную базу данных и т.д. Лично я ненавижу такие ситуации. Давайте посмотрим, как мы можем избежать её.

Руководителям разработки необходим четкий и понятный обзор состояния безопасности приложения и соответствия требованиям для их проектов. Декабрьский релиз GitLab поможет вам эффективнее отслеживать эти важные параметры.

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

Подключение к лаборатории осуществляется через VPN. Рекомендуется не подключаться с рабочего компьютера или с хоста, где имеются важные для вас данные, так как Вы попадаете в частную сеть с людьми, которые что-то да умеют в области ИБ :)

В продолжение предыдущей статьи про инструменты деплоя в Kubernetes, хочу рассказать вам про то как можно использовать Jsonnet для упрощения описания джоб в вашем .gitlab-ci.yml

Дано

Есть монорепа, в которой:

• 10 Dockerfiles
• 30 описанных деплоев
• 3 окружения: devel, staging и production

Задача

Настроить пайплайн:

• Сборка Docker-образов должна производиться по добавлении git-тэга с версией.
• Каждая операция деплоя должна выполняться при пуше в ветку окружения и только по изменении файлов в конкретной директории
• В каждом окружении установлен свой gitlab-runner с отдельным тэгом, который выполняет деплой только в своём окружении.
• Не все приложения должны быть задеплоены в каждое из окружений, мы должны описать пайплайн так, чтобы иметь возможность делать исключения.
• Некоторые деплойменты используют git submodule и должны запускаться с установленной переменной GIT_SUBMODULE_STRATEGY=normal

Описать это всё может показаться настоящим адом, но мы не отчаиваемся и вооружившись Jsonnet сделаем это легко и непринуждённо.

Предыстория

Ещё летом в официальном блоге BitBucket опубликовали запись, в которой сообщили об окончании поддержки репозиториев Mercurial.

Прекращение поддержки Mercurial будет проходить в два этапа:

1. С 1 февраля 2020 года пользователи больше не смогут создавать новые репозитории.
2. С 1 июня 2020 года пользователи не смогут использовать функции Mercurial в Bitbucket или через его API, а все репозитории Mercurial будут удалены.

С причинами такого решения всё более-менее понятно, но я в работе использую несколько репозиториев на Mercurial (Mercurial мне всегда больше нравился, но этот вопрос я оставлю за рамками данной статьи), которые потребовалось сконвертировать в GIT.

Системы контроля версий уже давно стали повседневным инструментом разработчика. В больших монорепозиториях требования к ним оказываются весьма специфическими. Из-за этого компании либо адаптируют существующие решения, как это делает Facebook с Mercurial и Microsoft с Git, либо разрабатывают собственные системы: Piper и CitC в Google и Arc VCS в Яндексе.

В докладе разработчик Владимир Кихтенко kikht рассказывает, зачем Яндексу понадобилась собственная система контроля версий и как она работает. Рассмотрим её со стороны рядового разработчика: как получить доступ к исходному коду, отвести ветку для разработки и интегрировать изменения в общую кодовую базу. Заглянем под капот — узнаем про внутреннее представление данных и их отображение в виртуальной файловой системе с рабочей копией. Обсудим трудности при реализации функций VCS в виртуальной файловой системе и при ленивой загрузке данных. Поговорим о том, как обеспечивать надежность серверной инфраструктуры репозитория. В конце можно посмотреть неофициальную запись доклада.

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

Данной статьей я начну публикацию решений отправленных на дорешивание машин с площадки HackTheBox. Надеюсь, что это поможет хоть кому-то развиваться в области ИБ. Мы рассмотрим, как можно проэксплуатировать RCE в API, покопаемся в репозиториях Gogs, поработаем с базами данных и разберемся c системой хранения и управления секретами Vault.

Подключение к лаборатории осуществляется через VPN. Рекомендуется не подключаться с рабочего компьютера или с хоста, где имеются важные для вас данные, так как Вы попадаете в частную сеть с людьми, которые что-то да умеют в области ИБ :)

Мы ушли на код-фриз и готовы подвести итоги — это был отличный год!

2019-й для Команды ВКонтакте — это 180 разработчиков мобильной и веб-версии, 71 398 коммитов в мастер и 4 459 обновлений продакшена. Мы собрали все числа в одно наглядное видео, чтобы зафиксировать статистику и заложить ещё более амбициозные планы на следующий год.

Пусть в 2020 году реализуются и все ваши планы! С наступающим!

В этой статье Senior App Dev Manager Джейсон Джордано (Jason Giordano) покажет нам, как использовать GitHub Actions для создания очень простого CI/CD решения.

GitHub Actions, релиз которого состоялся 13 ноября 2019 года, позволяет легко автоматизировать все ваши рабочие процессы в области программного обеспечения. Вы можете ознакомиться с подробностями здесь.



Также рекомендую ознакомиться с данной документацией перед тем, как решите расширить свое решение.

Привет!

В этом релизе мы сосредоточились на производительности и качестве. Вместе с другими командами JetBrains, мы занимались оптимизацией производительности, повышением отзывчивости интерфейса, улучшением существующей функциональности.

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

Мы также работали над поддержкой новых фреймворков для создания микросервисов, таких как Micronaut, Quarkus и Helidon, и сделали долгожданную поддержку MongoDB.

Вышел новый релиз GitLab с созданием и развертыванием кластеров EKS, поддержкой Crossplane, панелью окружений и многими другими классными фичами!

Сегодня мы расскажем о принципах и моделях GitOps, а также о том, как эти модели реализуются на платформе OpenShift. Интерактивное руководство на эту тему доступно по ссылке.



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

В этой статье сравним с технической точки зрения самые известные системы управления версиями (в будущем планируем расширить список):

1. Первое поколение
   
   • SCCS (Source Code Control System)
   • RCS (Revision Control System)
2. Второе поколение
   • CVS (Concurrent Versions System)
   • SVN (Apache Subversion)
3. Третье поколение
   • Git
   • Mercurial

Примечание от переводчика: это первая часть монументальной (на самом деле монументальной) статьи о Vim и его возможностях от разработчика из Миннеаполиса и автора проекта PostgREST Джо begriffs Нельсона.

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

---

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

Список литературы

Чтобы выйти за границы привычных тем, я бы порекомендовал обзавестись бумажной копией этого руководства и емким карманным справочником. Я не смог найти печатную копию руководства пользователя для Vim, так что в итоге просто распечатал идущий вместе с редактором PDF-файл с помощью printme1.com. Он идет вместе с софтом в $VIMRUNTIME/doc/usr_??. В качестве удобного списка команд могу посоветовать справочник «Vi and Vim Editors Pocket».

Содержание

• История
• Иерархия конфигурации
• Сторонние плагины
• Бекапы и откаты
• Include и path
• Редактирование и компиляция цикла
• Диффы и патчи
• Буфер ввода / вывода
• Типы файлов
• Не забывайте про мышь
• Разное

История

Рождение vi

Команды и функции Vi существуют уже более пятидесяти лет, начиная с редактора QED. Вот его таймлайн:

Оглавление

Предисловие
1. Настройка git
....1.1 Конфигурационные файлы
....1.2 Настройки по умолчанию
....1.3 Псевдонимы (aliases)
2. Основы git
....2.1 Создание репозитория
....2.2 Состояние файлов
....2.3 Работа с индексом
....2.4 Работа с коммитами
....2.5 Просмотр истории
....2.6 Работа с удалённым репозиторием
3. Ветвление в git
....3.1 Базовые операций
....3.2 Слияние веток
....3.3 Rerere
4. Указатели в git
....4.1 Перемещение указателей
5. Рекомендуемая литература

Предисловие

Git — самая популярная распределённая система контроля версиями.[1][2]

Основное предназначение Git – это сохранение снимков последовательно улучшающихся состояний вашего проекта (Pro git, 2019).

Прим. перев.: Эта публикация британского программиста, ставшая настоящим хитом в англоязычном интернете, ссылается на Git-коммит 6-летней давности. Он был зафиксирован в одном из открытых репозиториев Government Digital Service — службы, занимающейся развитием цифровых услуг в Великобритании и поддерживающей проект GOV.UK. Сам коммит интересен не столько изменениями в коде, сколько сопровождающим их описанием…


Картинка из xkcd #1296

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

Доброго дня

У нас имеется несколько облачных кластеров с большим количеством виртуальных машин в каждом. Все это дело у нас хостится в Hetzner'e. В каждом кластере у нас имеется по одной мастер-машине, с нее делается снэпшот и автоматически разносится по всем виртуалкам внутри кластера.

Эта схема не позволяет нам нормально использовать gitlab-runner'ы, так как возникает очень много проблем при появлении множества одинаковых зарегистрированных раннеров, что и побудило к нахождению обходного пути и к написанию этой статьи/мануала.

Вероятно, это не best practice, но это решение показалось максимально удобным и простым.

За туториалом прошу под кат.

Любой, кто использует Git, знает, что у него крутая линия обучения. Мы узнали от разработчиков, что большинство людей, как правило, учатся у знакомых, будь то коллега, профессор, друг или даже видео на YouTube. В GitHub Desktop 2.2 мы добавляем первую версию интерактивного учебника по Git и GitHub, который может стать вашим другом и помочь вам начать работу. Если вы новичок в Desktop, вы можете скачать и попробовать учебник по адресу desktop.github.com.