Tree of Dragons II by surrealistguitarist
Для тех, кто каждый день использует Git, но чувствует себя неуверенно, команда Mail.ru Cloud Solutions перевела статью фронтенд-разработчика Шейна Хадсона. Здесь вы найдете несколько трюков и советов, которые могут немного облегчить работу с Git, а также подборку статей и мануалов более продвинутого уровня.
Читать полностью »
Одной из базовых функций языка запросов Prometheus является агрегация временных рядов в режиме реального времени. Также язык запросов Prometheus можно использовать для обнаружения аномалий в данных временных рядов.
Команда Mail.ru Cloud Solutions перевела статью инженера команды инфраструктуры GitLab, где вы найдете примеры кода, которые сможете попробовать на своих системах.
Читать полностью »
- Все хорошо, только перед влитием обязательно засквош коммиты.
- Заскво...Что?Примерно такая реакция была у меня после получения апрува первого пул реквеста на первой неделе работы в одной крупной компании. Причина такой реакции весьма простая — далеко не каждый заказчик/работодатель может себе позволить такую роскошь как большая команда на одну платформу, в особенности это касается мобильной разработки. Из-за ненадобности и возможности быстрой коммуникации в своем мирке, далеко не все вещи, которые используют крупные мастера своего дела, обретают актуальность в небольших командах. Говоря проще — а на кой мне это надо, если мы и так хорошо без этого жили и хорошо справлялись?
После перехода в новую компанию я столкнулся с той же проблемой, но уже по другую сторону баррикад. Если вы еще не догадались о чем пойдет речь дальше — это GIT, говоря точнее, его встроенный инструментарий в AndroidStudio и как он позволяет сделать нашу работу проще.
Я постараюсь не обращать внимания на банальные вещи: init VCS; new/rename/push branch; rebase/merge onto branch; setup remotes e.t.c. Я постараюсь обратить внимание на те элементы, которые по боязни своего незнания, я долгое время избегал(и жалею).
Посмотрим, что происходит, когда вы выполняете git rebase и почему нужно быть внимательным.
Это вторая и третья части гайда по Git из блога Pierre de Wulf в переводе команды Mail.ru Cloud Solutions. Первую часть можно почитать тут.
Читать полностью »
werf — наша GitOps CLI-утилита с открытым кодом для сборки и доставки приложений в Kubernetes. В релизе v1.1 была представлена новая возможность в сборщике образов: тегирование образов по содержимому или content-based tagging. До сих пор типичная схема тегирования в werf предполагала тегирование Docker-образов по Git-тегу, Git-ветке или Git-коммиту. Но у всех этих схем есть недостатки, которые полностью решаются новой стратегией тегирования. Подробности о ней и чем она так хороша — под катом.Читать полностью »
Публикуем перевод статьи, которую мы нашли на hackernoon.com. Ее автор, Thiago Miranda, пишет о том, как сделать работу с Git более удобной и эффективной.
На днях вышла прекрасная, хотя и спорная статья — Please, stop using GitFlow! (и еще десяток на эту же тему после нее).
Ее основными тезисами были:
Но проблема GitFlow в том, что он и с монорепозиториями тоже не дружит.
Я сам об это споткнулся в процессе дизайна пайплайнов CI: GitFlow чудовищно мешает, когда работает поверх монорепозитория с несколькими deliverables, например, когда в одном репозитории отдельно и бэкэнд, и фронтэнд — уже из-за того, что он позволяет докоммичивать в релизные ветки, могут возникнуть конфликты при обратном мердже, если в один момент времени существует больше, чем одна релизная ветка. Да даже если одна, все равно плохо — в таких условиях надо патчить в принципе релизные механизмы GitFlow, чтобы хоть как-то заработали отдельные релизы сущностей.
В эпоху повсеместного CI/CD мы сталкиваемся с большим спектром сопутствующих инструментов, в том числе и CI-систем. Однако именно GitLab стал для нас самым близким, по-настоящему «родным». Заметную популярность он снискал и в индустрии в целом*. Разработчики продукта не отставали от роста интереса к его использованию, регулярно радуя сообщество разработчиков и DevOps-инженеров новыми версиями.
Агрегация по месяцам и тегам репозитория GitLab
GitLab — тот случай, когда активное развитие приносит множество новых и интересных возможностей. Если для потенциальных пользователей это просто один из факторов выбора инструмента, то для действующих — ситуация такова: если вы не обновляли свою инсталляцию GitLab последний месяц, то с большой вероятностью пропустили что-то интересное. В том числе и регулярно выходящие security updates.
О наиболее значимых — т.е. востребованных нашими DevOps-инженерами и клиентами — нововведениях в последних релизах Community-редакции GitLab и пойдет речь в статье.Читать полностью »
Прим. перев.: Новая статья с критикой полюбившейся многим Git Flow получила столь заметное внимание, что даже оригинальный автор модели обновил публикацию 10-летней давности, актуализировав свой взгляд на её применение сегодня. Публикуем перевод как самой критики, так и официальной реакции.
Git-flow — это методология ветвления и слияния, сильно популяризированная заметкой 2010 года под названием «A Successful Git branching model» (была переведена на хабре как «Удачная модель ветвления для Git» — прим. перев.).
За последние десять лет бесчисленное множество команд пали жертвой этого громкого названия и оказались — не побоюсь этого слова — откровенно облапошены. В своей заметке автор утверждает, что они успешно внедрили эту модель в проекты, но умышленно не раскрывает подробности проектов, которые привели к этой «успешности».
И это главная ошибка тех, кто верит данной публикации. Общеизвестен факт, что не все стратегии работают во всех ситуациях, со всеми людьми, во всех контекстах. И я утверждаю, что та же логика применима и к этой модели ветвления.
На этом можно заканчивать, так? Ну, не совсем. Наверняка некоторые из вас скептически отнеслись к моей цепочке рассуждений, поэтому давайте копнем поглубже и попытаемся понять, почему модель ветвления Git-flow должна поджариться на медленном огне.Читать полностью »
Я обычно всегда обходился без докера и думал, что докер нужен только для больших проектов в больших компаниях. Но однажды я увидел как работает докер в паре с гитлабом у моего товарища и понял, что мне все таки стоит его изучить. Однако, как обычно это бывает, одной подходящей статьи я не нашел — они были либо слишком сложные, либо не полные, либо подразумевали, что вы все знаете само собой. Мне пришлось долго искать различные источники, соединять все это вместе и в итоге у меня получилось сделать простенький проект и CI/CD для него.
Всю работу можно разделить на три части: на локальной машине, на гитлабе и на сервере.
Итак, для реализации проекта нам понадобится аккаунт gitlab и удаленный сервер с виртуализацией KVM или XEN.
На локальной машине необходимо установить docker.
