xargs -p2 буде запускати обидва білда одночасно (конкретно докер білд не буде одночасним на рівні докера, але усе інше що входить в етап білда — наприклад експорт може один одному мішати) і може відбуватися кілька пушів у тей самий реджестрі одночасно (що досить непогано ложить cloudflare r2 registry)
також якщо після wait буде вебхук (а там має бути вебхук), то можливі випадки коли обидва білди пройшли, в швидкі реджестрі пуши пройшли і усі чекають і нічого не роблять доки в повільний реджестрі не запушить

доречний коментар, дякую

У прикладі не буде рейскондішену відразу тому що все-таки робота (sleep random) виконається і group.add(1) відбувається з затримкою

Але і корректний приклад який ви привели також не є корректним, тому що правильно було б не додавати в існуючу группу `group`, а створити нову для елементів циклу і потім очікувати на неї.

це не буде очікування двох пайпів паралельно, це буде очікуватись в бекграунді спершу перший, потім другий.

так, не буде, тому що над кодом який ви процитували написано

Тут вже не вийде просто очікувати пайп, бо можна залочити самих себе.

ви взагалі як саме статтю читаєте? Типу кожен блок це бестпрактіс на вашу думку?

а щодо xargs — ну це один з варіантів, я взагалі можу штук десять інших варіантів написати і що? А так xargs -p з функцією не задовільняє умові «пушити в реджестрі паралельно» і «можна білдити лише один імедж одночасно»

це ж ілюстрація неіснуючих функцій

Як на мене, то дуже ускладнено. Я б простіше розбив на функції отаким чином

це ви щодо «наївного» варіанту сперечаєтесь? Я взагалі думав просто навіть без циклу написати щоб ілюструвати наївний підхід. Але ідея наївного підходу це як раз зробити з мінімумом логіки (там далі у статті окремий блок навіть про це є)

Як воно може пушити, якщо воно ще в процесі build?

так ви статтю дочитайте спочатку 😅 там же прямо під кодом написано

Але як передати інформацію від процеса білдера до процесів які пушать і процесів вебхуків?

Якщо ви не хочете читати статтю, то просто читайте останній блок коду, бо попередні це приклади, історія і роздуми

Та людина нагадала мені (не дуже ввічливо, але нагадала) що я не обновляв опис профілю останніх років з шість

Я у телеграмі потім ще невеличкий додаток зробив, думаю може бути цікавим і читачам доу

Якщо нам треба послідовно прочитати з двох процессів, то можна виконати щось на кшталт

Дебаг функція (простіше читати ніж strace)

log_with_sleep() {
    local label=$1
    echo «$(date +„%H:%M:%S.%3N“) starting${label}»
    sleep 1
    echo «$(date +„%H:%M:%S.%3N“) end${label}»
}

Простий приклад послідовного виконання і читання (увага на дату):

(log_with_sleep "-1"; log_with_sleep "-2") | cat
# 10:08:06.474 starting-1
# 10:08:07.482 end-1
# 10:08:07.488 starting-2
# 10:08:08.498 end-2

Але якщо ми хочемо послідовно прочитати, але виконувати функції паралельно, то можна зробити так:

cat <(log_with_sleep 1) <(log_with_sleep 2)
# 10:10:05.529 starting1
# 10:10:06.538 end1
# 10:10:05.529 starting2
# 10:10:06.537 end2

А якщо треба паралельно читати і паралельно виконувати то можна зробити дуже просто:

(log_with_sleep "-1" & log_with_sleep "-2"&  wait) | cat
# 10:11:43.079 starting-1
# 10:11:43.080 starting-2
# 10:11:44.094 end-1
# 10:11:44.094 end-2

Усе це можна комибінувати

(log_with_sleep "1"; cat <(log_with_sleep "2") <(log_with_sleep "3"); (log_with_sleep "3" & log_with_sleep "4" & wait); log_with_sleep "5") | cat
# 10:30:25.737 starting1
# 10:30:26.748 end1
# 10:30:26.754 starting2
# 10:30:27.763 end2
# 10:30:26.754 starting3
# 10:30:27.765 end3
# 10:30:27.773 starting3
# 10:30:27.775 starting4
# 10:30:28.786 end4
# 10:30:28.789 end3
# 10:30:28.796 starting5
# 10:30:29.805 end5

В общем статьи редактировать нельзя. Запросил удаление статей и профиля. Если не сделают, будут на кипре про GDPR рассказывать

Мы тут с девопсами удаляем статьи и профили :) Если ещё есть кто-то, кто хабром пользуется.

Это не я писал пост. Я исправляю только те вещи которые я вижу + сомневаюсь в качестве собранного материала (потому что то что знаю уже не правда)

McDonalds может давать заявления, что выходит из рф

Макдак это франшиза. Свои рестораны они закрыли, по франшизе уведомили что не будет поддержки (поставщики и оборудование). Следующий шаг который они могут сделать это ввести войска нато в сибирь чтобы закрыть макдак.

Аналогично по Apple - они, как поставщик могут запретить дистрибьюторам продавать их технику.

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

По шелу я ничего не знаю. Суть моих комментариев — сначала разберитесь в том что пишете, где зрада, а где — нет. Что бы усилия точечно работали на конкретные компании, а не на те, кто уже вышел и больше ничего сделать не могут.

а заблочили? Насколько я понимаю, они могут контролировать только международные платежи, а по остальным ну это просто nfc чип с шифрованием и инфой, банки сами между собой работают без привлечения серваков Мастеркард.

в каких магазинах? у них нет физических магазинов, только ритейлеры и в них только остатки старой техники продаются. Новое не поставляется

по apple тоже неправильно написано — они остановили продажи. Перед публикацией надо ж как-то собрать информацию?

КГАМ та шукання зради.

Mastercard и виза например не могут заблочить карты внутри по техническим причинам, даже если ничего общего с ними не имеют.

www.mastercard.com/...​on-of-russian-operations
Once the suspension of Mastercard network services is completed in the coming days, the company will have nothing to do with these transactions, including any ability to block them

Пожалуйста, перед тем как делать зраду, прочитайте внимательно стейтменты организаций. А то сейчас список выглядит скорее истерикой, чем аналитикой.

Хорошая статья. Но.

>Структура должна быть как можно более плоской, никаких начальников. Операционистов не должна волновать политика. Они не должны думать о том, «кто попросил это сделать», и оценивать задачи, основываясь на иерархии. Законно то, что логично. «Более прав» тот, кто лучше обосновывает.

Политика начинается тогда, когда нет структуры. Если нет человека который решает, тогда побеждает тот кто громче кричит. То что у вас крик измеряется логикой — ничего не решает. Рассуждайте так — есть заказчик, а есть исполнитель. Если к вашим исполнителям приходят два заказчика, то как исполнитель должен решить чью работу делать? Почему это должен решать исполнитель? Каким образом инженер может знать всё о том что надо продукту в конкретный момент и что важнее для продукта конкретно сейчас?
В маленьких бизнесах справедливо требовать от инженера знания продукта, но на самом деле это менее эффективно чем иметь продукт менеджера, который знает что надо продукту и который (которая, которые) является принимающим решение.

Иначе начинается самотрактовка нужд компании, блат, выбирание интересных задач вместо нужных. Может даже дойти до синдрома вахтера, когда какой-то человек будет считать что стабильность, например, важнее фичи. Или наоборот, что фича важнее стабильности.

>Люди должны быть самостоятельными. Соотношение goal driven против process oriented среди сотрудников должно быть максимально в пользу первых, но для баланса нужны и вторые.

Если вы выбраковывете людей тоннами, то goal driven ок. Задачи заканчиваются, надо оттачивать и улучшать. Я, как представитель goal driven людей отлично понимаю что я слаб в шлифовании и улучшении и поэтому часто нанимаю себе в команду именно process oriented person. Иначе всё быстро запилим, а потом все сидят выгорают над имплементацией и полировкой.

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

Это очень опасно. Видел человека, который запилил модули для терраформа, которые были просто врапперами над одиночными ресурсами к терраформу. Типа модуль с кучей переменных а внутри только один ресурс в котором подставлены переменные.

>Продукт использует пользователь. И он должен быть доволен. У нас не в ходу фраза «ну пускай кто делал, тот и разбёрется». Наш operantions — «затычка» в любой боли, которой ещё не найден конкретный хозяин.

Справедливо. Но если нет овнера, то как понять какая «боль» приоритетнее?

>всё должно отвечать на вопрос, «как создать ещё сто таких, чтобы было одинаковое и удобное»
противоречит нелюбви к автоматизации. Опять же, надо ли всегда думать о том как создать «сто таких» или иногда достаточно иметь какие-то супер уникальные штуки?

>По возможности, отсутствие неинтерактивных коммуникаций (вроде имейлов).

Имейлы важная часть общения, когда нужен не срочный, но обстоятельный ответ.

>По возможности, присутствие тикетной системы.

интересно, а когда тикетная система не нужна?

В общем статья хорошая и имплементация интересная, особенно если работает, но если честно иногда складывалось ощущение что вы забыли что единственный ключевой слоган девопс это единство приоритетов. Если у вас есть человек который разруливает приоритеты для ops и dev команды и сразу все команды отвечают за стабильность и за time to market, то это девопс. Если у вас такого человека нет, то девопс тоже может быть, но только до тех пор пока у всех в головах есть одинаковое понимание соотношения time-to-market и стабильности. Хотя, если честно, я наблюдал только случаи, когда начиная с двух человек одинакового понимания уже не было, была иллюзия одинакового понимания, которую было очень легко разбить.

В общем, победитель выбран — Nikolay Ovsiannikov. Поздравляшки, обнимашки.

Коменты жесть просто. Ребята хотят сделать большую конфу серьезного уровня, это сложно и такое надо только поддерживать!

прочитал что в первой истории даже испытательный срок не прошел. Ну ОК, то есть вы хотите иметь право уволить человека если он вам не понравится, но что бы человек работал у вас даже если ему что-то не нравится. Отличная логика.