Грубо говоря, вы перешли от команд, специализированных по технологиям, к кросс-функциональным? Вопросы. Как вы развиваете обмен опытом между командами? Начинает ли расти в таком случае специализация по бизнес-доменам? Т.е., доработка фичи не в команде, которая её делала, становится нерациональной? Как относятся тогда к этому разработчики, не надоедает работать над одним и тем же? Как это решаете?
Интересно, за какой период был пройден этот путь. Мне кажется, всего две книги помогли бы организовать то, к чему вы пришли: Алан Купер "Как привести дела в порядок" и Глеб Архангельский "Тайм драйв".
Был промежуток в моей жизни, когда происходило много важных дел одновременно: рождение ребенка, ремонт в квартире, переход из одной рабочей сферы (инжиниринг), где я руководил отделом, в другую, новую (IT), где так же сразу надо было выполнять функции руководителя, а также активно изучать технологии и передавать дела, сдавать завершающиеся проекты.
Эти книги мне помогли. У меня было всего 3 списка дел: на день, на неделю, на год (на месяц оказалось уже слишком длительное планирование для каких-то точных планов). Все задачи были связаны тэгами, был отдельный список тегов. Задачи, привязанные ко времени, имели напоминалки. Было несколько отдельных списков с "ситуационными" задачами, на которые были привычки просматривать перед уходом на работу/домой и т.д. Все хорошо работало в Wunderlist (Теперь Microsoft ToDo).
Следующим этапом развития мне кажется только какая-то такая система может стать: https://habr.com/ru/post/508672/ . Но мне пока хватает текущей.
Спасибо за статью. Сейчас выбираю фреймворк для оптимизации гиперпараметров. Подскажите, имели ли вы опыт с Optuna? Если да, можете сравнить с hyperopt?
Отличная статья, спасибо! Как раз изучал тему разворачивания JupyterHub на простаивающих мощностях. Не знал о Kubeflow. Подскажите пожалуйста лучшее решение для такого кейса:
Есть два сервера. Свободные ресурсы примерно равны. Могу выделить на первом 24 ядра / 16 Гб оперативки, а на втором 10 ядер / 32 Гб. Можно перегнать некоторую нагрузку по оперативке с первого на второй.
В идеале хотелось бы объединить этот ресурс созданием вычислительного кластера.
Возможно ли получить один мощный инстанс Jupyter Notebook и утилизировать объединённый ресурс для проверки ML теорий (устал по 3 часа ждать в google colaboratory :)?
Или, как вы пишете, лучше по максимуму освободить ресурс одной из машин и на ней поднять чистый JupyterHub? И имеет ли при этом смысл установка Kubeflow?
В компании я пока один начинающий дата-сатанист, но не исключено появление интереса у других моих коллег.
Практического опыта с kubernetes нет, поэтому рассматривал вариант ещё использовать OpenShift (чтобы за меня команды куберу слал).
Замечательный доклад. Поделился друг, который присутствовал лично).
Вопросы / замечания:
Когда вы дошли до реализации, был упомянут сервис централизованного управления нодами кассандры. Таким образом, при предыдущих расчетах надёжности, нужно помножить ещё на надёжность этого сервиса.
Вы хотите избавиться от затрат CPU и сетевых задержек, но каков будет сравнительный рост этих же затрат на синхронизации между нодами?
Появляются ли особенности получения консистентного бэкапа данных такой системы?
Не понял первый вопрос про то, что деплоим. Веб-приложение в интранете организации. Можно сказать, SaaS. Монолит.
Второй вопрос, если он про интерфейс — то в гитлабе всё это сделано очень удобно (ведь сам гитлаб разрабатывают в гитлабе, у них там сотни фич висят в работе). Вы можете практически любой свой воркфлоу оформить с помощью меток к задачам. Также у вас есть доска (типа Kanban), которая тоже работает на метках. А способ управления по-моему один — все участники процесса должны ревностно относиться к консистентности информации в задачах (см. 2й пункт обязательных составляющих типичного процесса разработки).
Сегодня наткнулся на то, что в GitLab 13.5 добавили возможность запуска дочерних pipeline вручную. Думаю, так тоже можно решить вопрос: всегда создавать пайплайн с одними ручными действиями, а каскад автоматических — уже в дочерних пайплайнах.
А, выкатку производить только в момент переключения. Да, мне нравится. Думаю, получение одного этого совета окупили труды по написанию статьи. Спасибо!
Так понимаю, речь о микросервисной архитектуре? У нас пока монолиты, но вот мои рассуждения:
Такая архитектура уже говорит о том, что проект довольно серьёзный, так что и располагаемые ресурсы должны быть соответствующие. Скорее всего, всё должно строиться уже на платформе Kubernetes. Оркестраторы, кроме прочих задач, в том числе должны помогать решать вопросы сложных архитектур и процессов разработки. Без дополнительной информации могу предположить только решение "в лоб" и затратное по ресурсам: да, таки "деплоить ещё десять рядом". По тому, как это реализовать — зависит от вашего приложения. Наверняка понадобятся ещё дополнительные инструменты для хранения артефактов вроде JFrog Artifactory, Nexus и т.п.
Интересная идея, спасибо! Ещё и заставляет поддерживать статусы в соответствии.
Но хотелось бы решение продумать ещё дальше и не ставить необходимость гонять статус туда-обратно, чтобы, когда при тестировании сделали замечания и, пока просто делаются промежуточные коммиты, не вызывать на них сборки.
1) Да, возможно для начинающих действительно проще воспользоваться готовым решением в облаке. Правда есть параноики, кто не любит держать свой код непонятно где и имеет собственные свободные серверные ресурсы в распоряжении. А ещё, с чего вы взяли, что omnibus deprecated? Нигде не найду таких тревожных новостей.
2) С Kubernetes не работал, поэтому ничего добавить не могу. Считаю, это "слегка" оверкилл для молодых команд :)
В принципе, повторюсь, конечно можно реализовать дальнейшие ограничения и автоматизации. Но в целом, GitLab не запускает следующие стадии, если предыдущая (с тестом) зафейлилась. А виды тестов — это скорее тема для отдельной статьи. Есть такой опыт борьбы с Selenium-ом. Если интересно — добавлю вариант в голосовалку для следующей статьи)
После прочтения остался вопрос: какой именно механизм позволяет демонстрировать каждую фича ветку? На стэйджинге в один момент времени поднята только одна ветка? Если да, то нужно каждый раз руками деплоить? Или все? Или все с открытыми МР-ами? Если так, то как переходит переключение, и как экономите ресурсы когда одновременно поднято 10+ веток?
Хорошие вопросы!
Демонстрировать позволяет то, что каждая ветка поднимает группу контейнеров по ключу --project-name, внутри которой стоит собственный реверс-прокси nginx и распределяет запросы. А вот на этом контейнере и вешаются уже ключевые метки, по которым Traefik и узнаёт, что появился новый сервис, на который можно перенаправлять запросы по правилу host=$CI_ENVIRONMENT_SLUG.dev.company.ru.
Поднимаются ветки только с открытыми Merge Request-ами. На стейджинге может быть поднято столько веток, сколько позволят ресурсы стейджинга. Именно вопрос экономии ресурсов заставил меня оставить кнопку выкатки в ручном режиме. Я пока так и не нашёл иного способа, чтобы не собирать ветки каждый раз при пуше (тэги тут неудобны). Буду рад, если поделитесь вашим опытом!
1) Как я в статье заметил, приведённый пример является лишь некоей готовой базовой идеей, от которой вы можете оттолкнуться, чтобы создать собственный workflow. Который будет соответствовать вашим потребностям, принятым практикам, философии)
Как, например, в приведённых ссылках на статьи от компаний, чье мнение однозначно стоит изучить, в принципе отказываются от принятой "классической схемы" и делают что-то своё. Даже каждая команда внутри одной компании.
Так что, конечно, вы можете договориться и обязать разработчиков тэгировать релизные пуши. Я решил уйти от этого "человеческого фактора" для упрощения процесса (хотя, конечно, можно и автоматизировать).
2) Это здорово, если в проекте у вас такое покрытие тестами, что вы безусловно верите зелёным галочкам. К сожалению, в моём случае тестами были покрыты лишь самые критические места.
Я думаю, к CD скорее приближает наличие такой необходимости (то есть, уровня продукта, требования к коду которого заметно вырастают, как я заметил в предупреждении к кейсу веб-разработки). А если вам это не нужно и предупреждённые пользователи вполне переживут запланированный на ночь минутный даунтайм, то лучше следовать правилу 80/20.
Что-то из ветки мастер, да. Но какой коммит? До или после той фичи, когда мы где-то тут (где сломалось) и вносили изменения?
"до конца проверенный мастер“. Это состояние в "классической схеме" соответствует итоговому состоянию release-ветки перед мержем в мастер. Эта ветка вам понадобится, если у вас ведётся разработка настолько интенсивно, что, когда вы интегрировали большое количество изменений, вам нужно время "устаканить" все возникающие при этом конфликты (stable-версия), когда при этом летят уже новые готовые изменения. Чтобы не быть в состоянии постоянного тестирования)
Грубо говоря, вы перешли от команд, специализированных по технологиям, к кросс-функциональным?
Вопросы. Как вы развиваете обмен опытом между командами? Начинает ли расти в таком случае специализация по бизнес-доменам? Т.е., доработка фичи не в команде, которая её делала, становится нерациональной? Как относятся тогда к этому разработчики, не надоедает работать над одним и тем же? Как это решаете?
Интересно, за какой период был пройден этот путь. Мне кажется, всего две книги помогли бы организовать то, к чему вы пришли: Алан Купер "Как привести дела в порядок" и Глеб Архангельский "Тайм драйв".
Был промежуток в моей жизни, когда происходило много важных дел одновременно: рождение ребенка, ремонт в квартире, переход из одной рабочей сферы (инжиниринг), где я руководил отделом, в другую, новую (IT), где так же сразу надо было выполнять функции руководителя, а также активно изучать технологии и передавать дела, сдавать завершающиеся проекты.
Эти книги мне помогли. У меня было всего 3 списка дел: на день, на неделю, на год (на месяц оказалось уже слишком длительное планирование для каких-то точных планов). Все задачи были связаны тэгами, был отдельный список тегов. Задачи, привязанные ко времени, имели напоминалки. Было несколько отдельных списков с "ситуационными" задачами, на которые были привычки просматривать перед уходом на работу/домой и т.д. Все хорошо работало в Wunderlist (Теперь Microsoft ToDo).
Следующим этапом развития мне кажется только какая-то такая система может стать: https://habr.com/ru/post/508672/ . Но мне пока хватает текущей.
Когда-то давно интересовался темой webNFC. Была идея связать корпоративное приложение с системой доступа в задании и парковке.
Но тогда требовало установки экспериментальных флагов в клиенте.
Спасибо за статью. Сейчас выбираю фреймворк для оптимизации гиперпараметров. Подскажите, имели ли вы опыт с Optuna? Если да, можете сравнить с hyperopt?
Да, похоже что я фундаментально ошибался и без дополнительных инструментов не обойтись. Спасибо!
Отличная статья, спасибо! Как раз изучал тему разворачивания JupyterHub на простаивающих мощностях. Не знал о Kubeflow. Подскажите пожалуйста лучшее решение для такого кейса:
Есть два сервера. Свободные ресурсы примерно равны. Могу выделить на первом 24 ядра / 16 Гб оперативки, а на втором 10 ядер / 32 Гб. Можно перегнать некоторую нагрузку по оперативке с первого на второй.
В идеале хотелось бы объединить этот ресурс созданием вычислительного кластера.
Возможно ли получить один мощный инстанс Jupyter Notebook и утилизировать объединённый ресурс для проверки ML теорий (устал по 3 часа ждать в google colaboratory :)?
Или, как вы пишете, лучше по максимуму освободить ресурс одной из машин и на ней поднять чистый JupyterHub? И имеет ли при этом смысл установка Kubeflow?
В компании я пока один начинающий дата-сатанист, но не исключено появление интереса у других моих коллег.
Практического опыта с kubernetes нет, поэтому рассматривал вариант ещё использовать OpenShift (чтобы за меня команды куберу слал).
Ого, дедушка и правда крут) Супер подарок!
Наконец меня порадовал дедушка из Владивостока :)
Замечательный доклад. Поделился друг, который присутствовал лично).
Вопросы / замечания:
Не понял первый вопрос про то, что деплоим. Веб-приложение в интранете организации. Можно сказать, SaaS. Монолит.
Второй вопрос, если он про интерфейс — то в гитлабе всё это сделано очень удобно (ведь сам гитлаб разрабатывают в гитлабе, у них там сотни фич висят в работе). Вы можете практически любой свой воркфлоу оформить с помощью меток к задачам. Также у вас есть доска (типа Kanban), которая тоже работает на метках. А способ управления по-моему один — все участники процесса должны ревностно относиться к консистентности информации в задачах (см. 2й пункт обязательных составляющих типичного процесса разработки).
Сегодня наткнулся на то, что в GitLab 13.5 добавили возможность запуска дочерних pipeline вручную. Думаю, так тоже можно решить вопрос: всегда создавать пайплайн с одними ручными действиями, а каскад автоматических — уже в дочерних пайплайнах.
Спасибо за отзыв, очень приятно)
Это здорово. С удовольствием ознакомлюсь с другими точками зрения)
А, выкатку производить только в момент переключения. Да, мне нравится. Думаю, получение одного этого совета окупили труды по написанию статьи. Спасибо!
Так понимаю, речь о микросервисной архитектуре? У нас пока монолиты, но вот мои рассуждения:
Такая архитектура уже говорит о том, что проект довольно серьёзный, так что и располагаемые ресурсы должны быть соответствующие. Скорее всего, всё должно строиться уже на платформе Kubernetes. Оркестраторы, кроме прочих задач, в том числе должны помогать решать вопросы сложных архитектур и процессов разработки. Без дополнительной информации могу предположить только решение "в лоб" и затратное по ресурсам: да, таки "деплоить ещё десять рядом". По тому, как это реализовать — зависит от вашего приложения. Наверняка понадобятся ещё дополнительные инструменты для хранения артефактов вроде JFrog Artifactory, Nexus и т.п.
Интересная идея, спасибо! Ещё и заставляет поддерживать статусы в соответствии.
Но хотелось бы решение продумать ещё дальше и не ставить необходимость гонять статус туда-обратно, чтобы, когда при тестировании сделали замечания и, пока просто делаются промежуточные коммиты, не вызывать на них сборки.
1) Да, возможно для начинающих действительно проще воспользоваться готовым решением в облаке. Правда есть параноики, кто не любит держать свой код непонятно где и имеет собственные свободные серверные ресурсы в распоряжении. А ещё, с чего вы взяли, что omnibus deprecated? Нигде не найду таких тревожных новостей.
2) С Kubernetes не работал, поэтому ничего добавить не могу. Считаю, это "слегка" оверкилл для молодых команд :)
Спасибо за спасибо!
В принципе, повторюсь, конечно можно реализовать дальнейшие ограничения и автоматизации. Но в целом, GitLab не запускает следующие стадии, если предыдущая (с тестом) зафейлилась. А виды тестов — это скорее тема для отдельной статьи. Есть такой опыт борьбы с Selenium-ом. Если интересно — добавлю вариант в голосовалку для следующей статьи)
Хорошие вопросы!
Демонстрировать позволяет то, что каждая ветка поднимает группу контейнеров по ключу
--project-name, внутри которой стоит собственный реверс-прокси nginx и распределяет запросы. А вот на этом контейнере и вешаются уже ключевые метки, по которым Traefik и узнаёт, что появился новый сервис, на который можно перенаправлять запросы по правилуhost=$CI_ENVIRONMENT_SLUG.dev.company.ru.Поднимаются ветки только с открытыми Merge Request-ами. На стейджинге может быть поднято столько веток, сколько позволят ресурсы стейджинга. Именно вопрос экономии ресурсов заставил меня оставить кнопку выкатки в ручном режиме. Я пока так и не нашёл иного способа, чтобы не собирать ветки каждый раз при пуше (тэги тут неудобны). Буду рад, если поделитесь вашим опытом!
1) Как я в статье заметил, приведённый пример является лишь некоей готовой базовой идеей, от которой вы можете оттолкнуться, чтобы создать собственный workflow. Который будет соответствовать вашим потребностям, принятым практикам, философии)
Как, например, в приведённых ссылках на статьи от компаний, чье мнение однозначно стоит изучить, в принципе отказываются от принятой "классической схемы" и делают что-то своё. Даже каждая команда внутри одной компании.
Так что, конечно, вы можете договориться и обязать разработчиков тэгировать релизные пуши. Я решил уйти от этого "человеческого фактора" для упрощения процесса (хотя, конечно, можно и автоматизировать).
2) Это здорово, если в проекте у вас такое покрытие тестами, что вы безусловно верите зелёным галочкам. К сожалению, в моём случае тестами были покрыты лишь самые критические места.
Я думаю, к CD скорее приближает наличие такой необходимости (то есть, уровня продукта, требования к коду которого заметно вырастают, как я заметил в предупреждении к кейсу веб-разработки). А если вам это не нужно и предупреждённые пользователи вполне переживут запланированный на ночь минутный даунтайм, то лучше следовать правилу 80/20.
Что-то из ветки мастер, да. Но какой коммит? До или после той фичи, когда мы где-то тут (где сломалось) и вносили изменения?
"до конца проверенный мастер“. Это состояние в "классической схеме" соответствует итоговому состоянию release-ветки перед мержем в мастер. Эта ветка вам понадобится, если у вас ведётся разработка настолько интенсивно, что, когда вы интегрировали большое количество изменений, вам нужно время "устаканить" все возникающие при этом конфликты (stable-версия), когда при этом летят уже новые готовые изменения. Чтобы не быть в состоянии постоянного тестирования)