Size: a a a

2020 August 03

SS

Slava Savitskiy in ctodailychat
Onlinehead
Жопа удаленки приходит где то через полгода и дальше. Когда окончательно теряется запас контекста, который был получен во время работы в офисе. Вот тогда и становится понятно, как на самом деле оно работает в конкретной команде.
вот да, мы все перешли на удаленку с уже сплоченными командами, где все всех знали лично. теперь прошло полгода и уже приходят новые люди только на удаленку - а бывшие еще не поняли, что такое когда все на удаленке
источник

O

Onlinehead in ctodailychat
Oleg
Интересует мнение чата, упоролись мы или нет) Мы мержим в мастер ветки как только прошел CI с автотестами и QA поставили аппрув. И у нас workflow построен так, что при выкате на стейджи мы всегда ветку патчим на свежий мастер, чтобы постоянно не подмерживать в нее свежий мастер, плюс, если есть конфликты оно сразу не выкатится и разработчик пойдет мержить и разбираться.
И вот мы переходим в k8s где образы вроде как уже заранее собраны на каждый коммит и думает как нам притащить туда наш workflow.
Пока есть идеи 2:
1) обновлять образы всех веток при каждом мерже в мастер
2) создать образ непосредственно перед каждым выкатом стейджа
Мне кажется вы слегка собрали в кучу сборку артефакта и непосредственно сборку кода. Для выкладки в кубик артефакт - это контейнер. Собирать-тестировать код в целом никто не мешает и без сборки артефакта. То есть да, вариант 2) выглядит логичным - работа с кодом и проверка собирается\нет живет сама по себе, а при выкладке просто добавляется шаг про генерацию артефакта и собственно деплой. Если собирать сильно дороже чем хранить, то можно результат сборки выделять опять же в артефакт и кэшировать его на недельку, при необходимости упаковывая в контейнер.
источник

O

Onlinehead in ctodailychat
Плюс, учитывая что в этом случае в сборку артефакта будет попадать уже код, призанный годным и по этому коду уже поидее прошлось все что можно, то сборку для контейнера можно делать уже без тестов и прочего подобного, что обычно занимает сильно больше времени чем непосредственно сама сборка.
источник

O

Oleg in ctodailychat
Onlinehead
Плюс, учитывая что в этом случае в сборку артефакта будет попадать уже код, призанный годным и по этому коду уже поидее прошлось все что можно, то сборку для контейнера можно делать уже без тестов и прочего подобного, что обычно занимает сильно больше времени чем непосредственно сама сборка.
Вцелом вы подтвердили мои мысли) у нас просто были разные дебаты о том что вообще это тру вей или нет
источник

O

Onlinehead in ctodailychat
Oleg
Вцелом вы подтвердили мои мысли) у нас просто были разные дебаты о том что вообще это тру вей или нет
Момент в сторону, но может пригодиться (не знаю много ли вы работали с такими системами) - не используйте один и тот же контейнер для сборки и деплоя. Артефакты должны собираться где-то во вне (хоть в другом контейнере мультистейджем) и только потом попадать в результирующий контейнер. Из-за особенностей работы onion файловых систем, он мало того что пухнуть будет, так еще и код/секреты могут утечь.
Я достаточно часто видел такие ситуации при подобных миграциях, т.к. среда непривычная и об этом часто забывают\не знают.
источник

O

Oleg in ctodailychat
Onlinehead
Момент в сторону, но может пригодиться (не знаю много ли вы работали с такими системами) - не используйте один и тот же контейнер для сборки и деплоя. Артефакты должны собираться где-то во вне (хоть в другом контейнере мультистейджем) и только потом попадать в результирующий контейнер. Из-за особенностей работы onion файловых систем, он мало того что пухнуть будет, так еще и код/секреты могут утечь.
Я достаточно часто видел такие ситуации при подобных миграциях, т.к. среда непривычная и об этом часто забывают\не знают.
Хм, интересно да. У нас вцелом особенно собирать нечего (ruby), только лишь фронт, там особо нечему утекать)
источник

O

Onlinehead in ctodailychat
Oleg
Хм, интересно да. У нас вцелом особенно собирать нечего (ruby), только лишь фронт, там особо нечему утекать)
Ну да, со скриптами не так страшно:) это скорее важно, если контейнеры куда то наружу отдаются.
источник

A

Alexander in ctodailychat
источник

MS

Max Syabro in ctodailychat
повод обновить телефон
источник

D

D0znpp in ctodailychat
Не совсем так, патч все-таки будет, скорее всего. Функционал чипа может быть ограничен на уровне выше, там идёт больше работа
источник

SG

Samat Galimov in ctodailychat
Я может не так читаю, но в твите ничего про Secure Enclave нет, только про jailbrake
источник

SG

Samat Galimov in ctodailychat
А у журналиста вдруг появилось. Откуда дрова?
источник

SG

Samat Galimov in ctodailychat
(Самат к 31 году жизни начал проверять первоисточники)
источник

DK

Dmitriy K in ctodailychat
"An expected scenario is for government agencies to use this security breach on confiscated devices."
источник

DK

Dmitriy K in ctodailychat
это не бага, это фича
источник

A

Alexander in ctodailychat
Samat Galimov
А у журналиста вдруг появилось. Откуда дрова?
https://www.mosec.org/en/2020/ думаю от того кто mosec смотрел 🙂
источник

A

Alexander in ctodailychat
D0znpp
Не совсем так, патч все-таки будет, скорее всего. Функционал чипа может быть ограничен на уровне выше, там идёт больше работа
Ограничить-то можно, но вот если за твоими данными охотятся. Потерял телефон - потерял данные. Серьёзный репутационный урон.
источник

SG

Samat Galimov in ctodailychat
источник

SG

Samat Galimov in ctodailychat
Ну вот смотри, в abstract написано, что можно говорить с SEP for testing
источник

SG

Samat Galimov in ctodailychat
Взлом SEP с похищением ключей - это круче, чем все атаки на Intel вместе взятые
источник