Рубрика «монорепозиторий»

в 9:00, , рубрики: ruvds_статьи, Блог компании RUVDS.com, Микросервисная архитектура, монолит, монолиты, монорепозиторий, Программирование, Разработка веб-сайтов, Софт, Управление продуктом, эффект Сенеки

Хорошие монолиты. Простая архитектура лучше всего - 1


Критика монолитов стала в индустрии обычным делом. Многие считают каким-то очевидным фактом, что распределённые (микро-)сервисы всегда лучше монолитных приложений, написанных от начала до конца как цельный неделимый независимый кусок.

Если вспомнить, то идея модульных микросервисов всплыла около десяти лет назад на подъёме идеологий гибкой разработки (Agile) и DevOps. Эти мощные концепции сильно повлияли на индустрию.

Но что мы видим спустя десять лет? В реальности нас окружает большое количество хороших монолитных приложений, которые великолепно работают без перехода на микросервисы. Как же так?
Читать полностью »

в 8:28, , рубрики: Анализ и проектирование систем, Блог компании Яндекс, высокие нагрузки, монорепозиторий, распределенные системы, системы сборки

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

Чем мы занимаемся

— Итак, давайте начинать. Наверняка все из вас каким-то образом связаны с IT и знают нормальный жизненный цикл или каждодневную работу разработчика. Он приносит основную ценность тем, что пишет код.
Читать полностью »

в 16:37, , рубрики: angular, canvas, javascript, machine learning, ml, react.js, ReactJS, svelte, SvelteJs, vue.js, vuejs, Блог компании IT-People, казань, монолит, монорепозиторий, фронтенд

«Все об этом говорят, некоторые понимают, (как они думают), а занимаются, по-настоящему, лишь единицы» — цитата программного директора DUMP Казань. Если вы думаете, что вы тертый калач фронтенд, и ничего нового на конференциях не услышите, то загляните на frontend-секцию 8 ноября. Мы вспотели, пока слушали мат.часть некоторых докладов и истории взлетов-падений.

Темы секции Frontend на DUMP Казань: ML для фронтенд-разработчика, пиксельная магия, SvelteJS, смех, пот и слезы - 1
Читать полностью »

в 7:05, , рубрики: Bootstrap, Git, javascript, jest, lerna, Блог компании Яндекс, интерфейсы, монорепозиторий, системы сборки, управление разработкой

Моё имя Азат Разетдинов, я в Яндексе уже 12 лет, руковожу службой разработки интерфейсов в Я.Недвижимости. Сегодня я хотел бы поговорить про монорепозиторий. Если у вас всего один репозиторий в работе — поздравляю, вы уже живете в монорепозитории. Теперь о том, зачем он нужен другим.

Разработка в монорепозитории. Доклад Яндекса - 1

Как сказала руководитель службы разработки API Яндекс.Карт Марина Перескокова — посадил дед монорепу, выросла монорепа большая-пребольшая.

Читать полностью »

в 10:17, , рубрики: code review, github, автоматические тесты, Блог компании Яндекс, интерфейсы, монорепозиторий, общий код, релизный цикл, тестирование, Тестирование веб-сервисов, управление разработкой

Создание и сопровождение общих компонентов — процесс, в котором должны быть заняты множество команд. Руководитель службы общих компонентов Яндекса Владимир Гриненко tadatuta объяснил, как их разработка переросла выделенную команду «Лего», как мы сделали монорепозиторий на базе GitHub с помощью Lerna и настроили Canary-релизы с внедрением в сервисы прямо в CI, что для этого понадобилось, а что ещё предстоит.

Общие компоненты силами разных команд. Доклад Яндекса - 1

— Рад вас всех приветствовать. Меня зовут Владимир, я занимаюсь общими штуками в интерфейсах Яндекса. Про них и хочу поговорить. Наверное, если вы не очень глубоко пользуетесь нашими сервисами, у вас может возникнуть вопрос: что мы все верстаем? Что там верстать?

Читать полностью »

в 11:00, , рубрики: css, end-to-end, enzyme, java, javascript, jest, Puppeteer, React, ReactJS, selenium grid, Блог компании Яндекс, интеграционное тестирование, модульное тестирование, монорепозиторий, Тестирование веб-сервисов

Стремление уйти от ручного регрессионого тестирования — хороший повод внедрить автотесты. Вопрос, какие именно? Разработчики интерфейсов Наталья Стусь и Алексей Андросов вспомнили, как их команда прошла несколько итераций и построила тестирование фронтенда в Авто.ру на базе Jest и Puppeteer: юнит-тесты, тесты на отдельные React-компоненты, интеграционные тесты. Самое интересное из этого опыта — изолированное тестирование React-компонентов в браузере без Selenium Grid, Java и прочего.

Полный цикл тестирования React-приложений. Доклад Авто.ру - 1

Алексей:
— Для начала надо немного рассказать, что такое Авто.ру. Это сайт по продаже машинок. Там есть поиск, личный кабинет, автосервисы, запчасти, отзывы, кабинеты дилеров и многое другое. Авто.ру — очень большой проект, очень много кода. Весь код мы пишем в большой монорепе, потому что это все перемешивается. Одни и те же люди делают схожие задачи, например, для мобильных и десктопа. Получается много кода, и монорепа нам жизненно необходима. Вопрос — как ее тестировать?

Читать полностью »

в 7:52, , рубрики: javascript, jest, lerna, monorepo, npm, YARN, yarn workspaces, архитектура, монорепозиторий

learn-and-yarn

За последние несколько лет концепция монорепозиториев успешно зарекомендовала себя, так как позволяет значительно упростить процесс разработки модульных программных проектов, таких как инфраструктуры на основе микросервисов. Основные преимущества такого архитектурного подхода очевидны на практике, поэтому предлагаю создать свой тестовый монорепозиторий с нуля, попутно разбираясь в нюансах работы с yarn workspaces и lerna. Ну что ж, начнём!

Рассмотрим структуру нашего проекта, который будет представлять собой три библиотеки расположенные в папке packages/, а также package.json в корневой директории.

├── package.json
└── packages
    ├── app
    │   ├── index.js
    │   └── package.json
    ├── first
    │   ├── index.js
    │   └── package.json
    └── second
        ├── index.js
        └── package.json

Подразумевается, что у нас есть две независимые библиотеки first и second, а также библиотека app, которая будет импортировать функции из первых двух. Для удобства все три пакета помещены в директорию packages. Можно было оставить их в корневой папке или поместить в директорию с любым другим именем, но, для того чтобы следовать общепринятым конвенциям, мы разместим их именно таким образом.
Читать полностью »

в 14:11, , рубрики: bazel, Git, monorepo, монорепозиторий, системы сборки, Системы управления версиями, управление разработкой

Всем привет!

Итак, новая порция обещанного холивара про монорепозитории. В первой части мы обсуждали перевод статьи уважаемого инженера из Lyft (и ранее Twitter) о том, какие есть недостатки у монорепозиториев и почему они нивелируют почти все достоинства этого подхода. Лично я во многом согласен с доводами, приведенными в оригинальной статье. Но, как и обещал, чтобы поставить точку в этом обсуждении, я бы хотел озвучить еще несколько моментов, на мой взгляд даже более важных и более практических.
Читать полностью »

в 6:37, , рубрики: Git, монорепозиторий, перевод, Системы управления версиями, управление разработкой

От переводчика: Привет, Хабр! Да, это очередная статья о преимуществах и недостатках монорепозиториев. Собирался написать свою статью о том, как мы используем монорепозиторий, как мы переходили с maven на bazel и что из этого получилось. Но пока собирался с мыслями, вышла отличная статья от разработчика из Lyft, которую я и решил для вас перевести. Обещаю опубликовать свои дополнения к статье, а также опыт с bazel в виде продолжения.

Мы в Новом 2019 году, и я настроен на еще одну дискуссию о преимуществах (или отсутствии таковых) в хранении всего исходного кода организации в «Монорепозитории». Для тех из вас, кто не знаком с этим подходом, идея состоит в том, чтобы хранить весь исходный код в едином репозитории системы контроля версий. Альтернатива, конечно, заключается в том, чтобы хранить исходный код в нескольких независимых репозиториях, разделяя их обычно по границе сервисов/приложений/библиотек.
В данном посте я буду называть такой подход «полирепозиторий».
Читать полностью »

в 8:20, , рубрики: Git, github, крупные проекты, монорепозиторий, Разработка под Linux, системное программирование, Системы управления версиями, ядро Linux

Некоторое время назад на отличной конференции maintainerati я пообщался с несколькими друзьями-мейнтейнерами о масштабировании по-настоящему больших проектов open source и о том, как GitHub подталкивает проекты к определённому способу масштабирования. У ядра Linux абсолютно иная модель, которую мейнтейнеры-пользователи GitHub не понимают. Думаю, стоит объяснить, почему и как она работает и чем отличается.

Ещё одной причиной для написания этого текста стала дискуссия на HN по поводу моего выступления «Мейнтейнеры не масштабируются», где самый популярный комментарий сводился к вопросу «Почему эти динозавры не используют современные средства разработки?». Несколько известных разработчиков ядра энергично защищали списки рассылки и предложение патчей через механизм, похожий на пулл-реквесты GitHub, Но по крайней мере несколько разработчиков графической подсистемы хотели бы использовать более современный инструментарий, который гораздо легче автоматизировать скриптами. Проблема в том, что GitHub не поддерживает тот способ, которым ядро Linux масштабируется на огромное число контрибуторов, и поэтому мы просто не можем перейти на него, даже для нескольких подсистем. И дело не в хостинге данных на Git, эта часть явно в порядке, а дело в том, как на GitHub работают пулл-реквесты, обсуждение багов и форки.
Читать полностью »

12
Главная   |  Архив новостей  |   Android  |   Google  |   Apple  |   Microsoft  |   Информационная безопасность  |   Веб – разработка
Публикации RSS  |  Комментарии RSS
https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js