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

Поговорим мы о секретах в общем, но с практической точки зрения сфокусируемся именно на работе с секретами на машинах разработчиков: как их туда безопасно доставить и употребить.

Этот текст — продолжение серии CI/CD в каждый дом, в прошлый раз мы обсуждали, как организовать сборочный цех базовых docker-образов.

TL;DR: На dev-тачках должны светиться только персональные/локальные секреты. Короткоживущие секреты лучше вечных. Храним безопасно. Передаём шифрованно. Употребляем сессионно.

Привет, Хабр.

Последнее время DevOps и CI/CD де-факто стали повсеместным стандартом независимо от размера команды, в интернетах хватает статей, почему это важно, в чём собственно идея, полезных практик и других материалов. Я же решил подойти с несколько другой стороны и максимально доступным языком на практических примерах рассмотреть отдельные задачи и их решения в рамках концепции.

Одной из таких задач, которую я хотел бы рассмотреть первой, является задача создания сборочного цеха базовых docker-образов, используемых в репозиториях и процессах проекта. 

Кому, собственно, это может пригодиться? Я бы сказал, что почти кому угодно, кто хочет организовать ту компоненту CI/CD, которая отвечает за построение и релизный цикл базовых образов внутри инфраструктуры вашей компании или даже персональных проектов (зародился он именно в процессе приведения в порядок моих пет-проектов).

Какой практический пример может быть без публичного репозитория с MIT-лицензией? Если вам не интересно читать статью, то можно прямо из превью перейти по ссылке и напитаться кодом. Репозиторий же можно копировать как целиком, так и кусками, буду только рад, если он кому-нибудь пригодится. На любые вопросы — готов ответить в комментариях или issues.

Эта статья является некоторым логическим продолжением предыдущей — «Техсобесы — это просто, но есть нюанс…». Я делился своим опытом прохождения технических собеседований, и в комментариях отметили, что это очередная статья о том, как соискатель должен выполнить всю работу за рекрутера. Поэтому сегодня я постараюсь взглянуть на процесс с другой стороны стола.

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

TL;DR: Знайте границы. Не расслабляйтесь. Готовьтесь и не тратьте время впустую. Понимайте зачем. Ищите релевантное. Проверяйте базу, а не частности. Понимание важнее знания. Задачи совсем не про код. Будьте открыты. Будьте таким интервьюером, которого хотели бы видеть с той стороны стола. Успехов!

Привет, Хабр. Меня зовут Дима и я разработчик, тимлид и по совместительству наставник на курсе «Мидл Python-разработчик» в Практикуме. Сегодня, с вашего позволения, я вставлю свои пять копеек и поделюсь опытом по такой заезженной теме, как технические собеседования. Много слов сказано, статей написано и копий сломано на сей благодатной почве, потому постараюсь быть максимально кратким.

Не буду писать много о себе, скажу лишь одно: я провёл много часов по обеим сторонам стола. Уповаю на то, что смогу кому-то быть полезным в этом нелёгком и, кажется, поднадоевшем деле. Я практически не буду затрагивать другие этапы, сконцентрируюсь только на техническом собеседовании и процессе подготовки к нему.

TL;DR: Внимательно читайте вакансию и анализируйте результат собеседования. Говоря о себе, фокусируйтесь на релевантном для слушателя. Будьте готовы ответить за обозначенный опыт. Задачи совсем не про код. Задавайте вопросы, интересуйтесь. И помните — «г-г-главное  н-н-не бояться». Успехов!