В октябрьском дайджесте собрали инциденты, которые точно пощекотали нервы ИБ-отделам пострадавших компаний. На хэллоуинской повестке – миллионная афера с мертвыми душами, хакер, смертельно обиженный непризнанием заслуг, и страшно частые атаки на геймдев.
Кому нужная новая VCS, когда уже есть Git, Mercurial, SVN, Perforce, Darcs и прочие? Автор проекта Jujutsu считает, что ещё есть куда рости. Знакомтесь — Martin von Zweigbergk из Google работает над проектом Jujutsu, или для краткости jj.
Чем он лучше чем ваша система контроля версия?
Дисклеймер: если ты продвинутый разработчик с Х годами опыта, пожалуйста, закрой эту статью. Здесь ты не найдешь абсолютно ничего полезного для себя.
Итак, небольшое вступление. Когда мне впервые пришлось делать коммит на GitHub, я помню, что перерыла кучу источников, и везде все было как-то не так, как в итоге сделала я.
В этой статье я расскажу о том, как сделать первый коммит на GitHub, и как делать последующие. Только мой опыт и сочетание консоли и фич IntelliJ Idea + у меня mac os, поэтому здесь именно про него (важно для установки).
Погнали.
Привет, я Александр, разработчик из команды Битрикс24. В этой статье разбираюсь в особенностях распределенной системы управления версиями Mercurial. Хотя она появилась одновременно с Git и похожа на него внешне, успеха достичь не смогла. Почему так получилось, как она работает, для каких проектов подходит — обо всем ниже.
Вот вам карты «возможного» местоположения разработчиков Telegram и React для затравки.
Telegram Desktop. Всего 205 человек. Из них 3 основные. Из них два (работают с 2014 и 2019) в районе Самара-Кавказ (Армения, Грузия, Азербайджан) и один (работает с 2018) вероятно в Турции.
ReactJS. Всего 1854 человек. Основной состав: 14 работает, 26 уволилось. Примерно 50/50 сидят на восточном и западном побережье США.
Недавно я пытался объяснить коллеге, какие у меня критерии при формировании пул реквеста — когда стоит объединять что‑либо в один пул реквест, а когда нет. И я заметил за собой фразу «ну, кроме…» несколько раз и решил записать, как я использую git — чтобы разобраться в особенностях моего подхода, как я мог бы улучшить его и, возможно, поделиться чем‑то полезным.
Поскольку это интернет, давайте сразу обговорим: то, как я использую git основывается на последних 12 годах работы в компаниях с относительно небольшими (до 50 человек) командами. В каждой из них мы использовали только git и GitHub; изменения выполнялись в отдельных ветках, предлагались в виде пул реквестов и сливались в основную ветку. В последние несколько лет, после введения GitHub squash‑merging, мы использовали его.
Я никогда не использовал какую‑либо другую систему контроля версий. Я не могу и не буду сравнивать git с Mercurial, jj, Sapling, и т. д.
Итак, вот как я использую git.
Недавно мы опубликовали в блоге перевод статьи о том, как GitHub заменил SourceForge в роли доминирующей платформы для хостинга кода. Но, как справедливо отметил автор оригинала, его мнение основано на открытых источниках и интервью с коллегами. А потом своим ви́дением поделился один из сооснователей GitHub, Скотт Чакон, который «действительно был там». Под катом — перевод его ответной статьи о реальных причинах победы GitHub.
Линус Торвальдс как-то написал в своей книге, что создавал Linux для развлечения, но в итоге это привело к революции. Git, его второе творение, также оказалось «случайной революцией» — и сегодня это стандартный инструмент для людей в ИТ. Однако процесс его создания был уже не таким «весёлым» — по крайней мере, для самого Линуса.
Привет, Хабр! Если вы давно искали подборку полезных статей по Git и Gitflow — загляните в блог beeline cloud. Здесь я делюсь личным опытом, погружаюсь в задачи из практики и даю развернутые комментарии на конкретную тему.
И да, меня по-прежнему зовут Николай Пискунов, я руководитель направления Big Data. Сегодня поговорим о том, что делать, если баг, несмотря на усилия тестировщиков, все же попал в прод.
Привет! Меня зовут Константин Белкин, я Teamlead SRE в РСХБ‑Интех. Сегодня расскажу вам, что такое CI/CD на платформе App.Farm, какие методологии мы используем в работе, как работает платформа, какие инструменты мы предоставляем разработчикам и каким образом мы организовали CI/CD в РСХБ для наших любимых разработчиков.
Если и есть инструмент, который на 100% обязаны освоить все слушатели ИТ‑курсов и начинающие разработчики еще в начале карьеры — то это Git. Книга «Изучаем Git: пошаговое руководство с наглядными примерами» (Learning Git. A Hands‑On and Visual Guide to the Basics of Git) от издательства O'Reilly Media, в переводе от Alist (БХВ Петербург) — это руководство «с нуля» по самой популярной системой контроля версий. Изложены основы Git: установка, графический интерфейс и командная строка, локальные репозитории и коммиты, ветки и слияния.
Всем привет! Если вы работаете с Kubernetes, то, скорее всего, используете kubectl, kustomize или Helm для развёртывания сервисов в кластере. Про последнюю утилиту я уже писал статью — можно посмотреть тут. Тогда я рассказал о своём опыте внедрения этого инструмента для собственных нагрузок и сравнил подходы kubectl apply и helm install.
Управление конфигурацией в Kubernetes может осуществляться с помощью различных инструментов. Помимо Helm, можно использовать просто YAML-манифесты или же kustomize. Для каждого из этих инструментов предусмотрена своя команда.
В данной статье мы рассмотрим подход GitOps для K8s-кластеров и применим такой инструмент, как Argo CD.
Всё уже придумано, просто настрой под себя и пользуйся.
Всем привет, я Дмитрий Валеев — DevOps инженер в команде разработки фреймворка для тестирования устройств на заводах Аквариус. И это моя первая маленькая статья на Хабр:)
В любом проекте настаёт день «икс», когда вы понимаете, что необходимо внедрять какое‑либо версионирование. Вот и в нашем случае настал такой момент. Вариант с хэш‑коммитами казался просто хаосом и нужно было привести вид компонент в порядок.
В GitLab CI пайплайны выполняют основную роль в автоматизации процессов CI/CD. Они позволяют разбить весь процесс сборки, тестирования и деплоя на отдельные, логически связанные задачи — или "джобы". Эти джобы структурируются в стадии, каждая из которых представляет собой определенный этап работы — например, сборка, тестирование или развертывание. Такое разделение позволяет ускорить разработку и минимизировать ошибки при доставке кода на продакшн.
В этой статье рассмотрим, как настроить пайплайн с разделением на стадии в GitLab CI.
Мы постоянно используем высокоуровневые команды git, такие как git add и git commit. Однако также существует другая группа команд git, которые обрабатывают низкоуровневые операции.
В этой статье мы создадим git‑коммит, используя низкоуровневые операции, а не команду git commit.
Меня зовут Дмитрий Прохоров, я пентестер из команды CyberOK. Часто на проектах по пентесту, а также в программах Bug Bounty встречаются Gitlab-ы. И встречаются они не только специалистам по ИБ, но и злобным хакерам, которые не прочь завладеть секретами репозиториев и даже исполнить код на сервере!
Сегодня я бы хотел посвятить свой монолог тем, кто любит приоткрывать завесу тайн своего Gitlab через функционал Explore и показывать интересные кейсы из Bug Bounty и пентестов, где небольшая мисконфигурация приводит к тяжелым последствиям.
Бывает, что в командах тестирования грезят об автоматизации процессов, но почему-то боятся внедрять даже такие простые вещи как хуки: «Они очень усложняют процесс, и писать их тысячу часов». С этим я категорически не согласен, ведь реализовать хуки очень просто.
Меня зовут Денис Федоров, я тестировщик в команде 2ГИС ПРО, сервисе геоаналитики для бизнеса. Рассказываю, что такое гит-хуки, чем они могут быть полезны и как их можно реализовать у себя.
Одна из важных задач при разработке отказоустойчивой распределенной системы — синхронизация данных на мастер‑узле со слейв‑узлом. В дальнейшем будем звать слейв‑узлы репликами. Методов синхронизации множество, и иногда более эффективным оказывается тот, который учитывает специфику хранимых данных.
Я Роман Соловьев, ведущий ИТ‑инженер в отделе RnD и готовых решений Управления развития продукта в СберТехе. Сегодня расскажу о том, как мы синхронизируем Git‑репозитории на двух узлах, какие существуют альтернативы и зачем это вообще нужно.
Расскажу про свой опыт прохождения интенсива в Школе 21 от Сбер.
В нем донесу много того, что поможет тебе принять решение идти или не идти на интесив!
Друзья, приветствую!
Если вы следите за моими статьями, то знаете, что на Хабре у меня опубликовано более 10 объемных публикаций на тему разработки телеграмм ботов через замечательный Python-фреймворк Aiogram 3.
Так получилось, что всю разработку я описывал в формате поллинга и, если для учебных и небольших проектов это подходит, то для крупных проектов нет, так как такой метод не оптимальный, медленный и требует больших ресурсов.
И, как вы догадались из названия статьи, сегодня я расскажу вам как, без особых заморочек и трудностей, перейти от поллинга к вебхукам. Прочитав эту статью у вас больше не будет страха перед настройкой, запуском и работой с такими ботами.
Из необычного, я продемонстрирую как без трудна запускать бота на вебхуках с локального компютера и как, в пару команд, развернуть такого бота на удаленном хостинге, не заморачиваясь с NGINX, протоколами, настройками серверов и прочее.
В общем, будет интересно и позновательно!
