Що треба знати Software Engineer з DevOps-інструментів

Автори статті: Микола Орлов, Head of DevOps office у компанії ELEKS. Понад 14 років досвіду в IT-сфері, зокрема робота з проєктами в банківській сфері, e-commerce, health care, мультимедіа тощо. У резюме успішні сетапи інфраструктури з нуля та управління девопс-командами різних розмірів.

Станіслав Міщишин, Senior Software Engineer у компанії ELEKS, де працює на одному з проєктів як Back-end Node.js Developer, брав участь у багатьох Devops-задачах на проєкті.

Якщо проєкт стартує без DevOps-спеціаліста, то найчастіше його завдання виконує інженер. Ця стаття про те, які DevOps-завдання вирішує девелопер, які речі є критичними для становлення проєкту і на що потрібно звернути особливу увагу, які тулзи потрібно знати, щоб впроваджувати девопс-методологію на проєкті. А також про низку практик, які потрібно підучити програмісту, щоб стати конкурентним на ринку, підвищити ефективність робочих процесів чи якість продукту.

Цей матеріал буде корисним також для тих розробників, які хочуть спробувати займатись DevOps-задачами на проєкті.

Ілюстрація Анастасії Авдєєвої

Коли розробник виконує DevOps-роботу

Коли проєкт занадто малий для залучення повноцінного девопса або всі девопси зайняті іншими задачами, девелопер виконує його функції. Спершу — це конфігурація локального розгортання проєкту: вибір інструментів, їх конфігурація, написання скриптів.

У 2017 році ми запустили проєкт, на який було виділено три девелопери. Проєкт був на стадії PoC, і у нас не було девопса. Нам було необхідно засетапити деякі критичні для девелопменту процеси, наприклад Gitflow, базову конфігурацію локального середовища.

Пізніше до проєкту долучились тестери, і потрібно було зробити процеси для розгортання продукту на ремоутний сервер. Для цього ми використали локальний Jenkins, написали декілька пайплайнів для збирання контейнерів (проєкт був базований на докері, тому також провели роботу з написання базових докер-файлів), підняли декілька віртуальних машин для тестування і створили ще пайплайн для, власне, самого деплойменту.

Цей підхід був дещо примітивний, але успішно пропрацював до залучення професійного девопса на проєкт.

Загалом для initial project setup необхідними знаннями буде, наприклад, docker/docker-compose, bash scripts, vagrant, etc. Інструменти можуть бути загально вживаними (наприклад, docker) або специфічні до стеку проєкту (npm, maven, ant gradle, webpack).

Наступною фазою може бути впровадження VCS version control system, вибір Gitflow, інтеграція зі встановленими SDLC-процесами на проєкті. Наприклад, введення policies на VCS-провайдері щодо обмежень на мержу процесу перегляду пулу запитів.

Налаштування CI/CD

Під час активного розвитку і масштабування проєкту важливим є етап continious integration/continious deployment. Особливо коли потрібно автоматизувати SDLC-процеси.

Ще один кейс — відточення CI-процесів. Ми вирішили використати Bitbucket pipelines, оскільки використовували сам Bitbucket і Jira — Bitbucket pipelines має велику кількість готових інтеграцій з ними. Для нашого стеку ми обрали eslint/tslint, низку js тестових фреймворків, SonarQube для аналізу code quality, також писали на bash-скриптах специфічні степи для проєкту.

На наших проєктах CI, як правило, охоплює налаштування інструментів для перевірки і вимірювання метрик code quality (наприклад, використовуючи SonarQube), юніт-тести, code coverage, створення і пабліш білд-артефактів.

Коли на проєкті є Automation QA, їм також може бути необхідна підтримка з DevOps-питань, наприклад, щодо інтеграції з інфраструктурою.

Над CI зазвичай працюють і девелопери, і девопси. Розробка continuous integration flows на проєкті відбувається постійно, оскільки будь-які зміни вимагають і зміни CI-процесів.

Створення ремоутного середовища

Створення ремоутного середовища критично важливе завдання на початковій стадії проєкту. Його зазвичай виконує девопс, але якщо на проєкті його немає, то це завдання розробників.

Трапляється, що середовище створюють вручну, без застосування автоматизованих скриптів, тоді існує велика ймовірність, що у майбутньому будуть складнощі з правильною побудовою deployment-процесів.

Інструменти можна обирати для цих процесів будь-які, зважаючи на проєкт та побажання клієнта: cloud або on-premise solution, віртуальна машина або лямбда-сервіси.

Найбільш поширеними cloud-провайдерами є AWS, Azure, GCP. Також є проєкти, які повністю побудовані на cloud-технологіях, тому навіть розробникам необхідно орієнтуватися, як це працює на ремоуті і як розгорнути це локально.

Для автоматизованого деплою є широкий вибір інструментів для різних цілей: Terraform, Helm, Ansible playbooks, Chef, Puppet.

Часто необхідно вносити зміну в наявні схеми деплою. Найпоширенішим кейсом є додавання/зміна environment variables.

Ще одне девопс-завдання, яке часто виконує девелопер — конфігурація вебсервера (NGINX, Apache, IIS). Це актуально для вебпроєктів, зокрема, фронтендщикам. Натомість для бекенд-розробників актуальна конфігурація вебсервера як реверс-проксі, якщо, наприклад, використовується Kubernetes — це інгрес. Також можна використовувати і cloud specific solution.

Нерідко виникають задачі, які містять конфігурацію NGINX — наприклад, конфігурації кешування, роутингу, інші параметри.

Фейли на проєкті, коли не було девопса

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

Але проблема у тому, що розробник не завжди бачить картину проєкту повністю, а у його зоні відповідальності, до якої він звик, — конкретний функціонал. А тут ще додається інфраструктура, CI/CD тощо.

Звісно, є ризик, що він чогось не враховує чи не побачить, чогось не знає. Тоді найкраще радитись з архітектором.

У випадках, коли проєкт стартує без девопса, трапляються спроби вирішити поточні таски «тут і зараз»: «зробити щонайскоріше, а далі розберемося». Так цілей, можливо, і досягають швидко, але стратегічно це призводить до проблем із залежностями у майбутньому. Це очікувано: рішення, які робляться «на коліні» складно масштабувати.

Хороший DevOps-спеціаліст має у своєму арсеналі кілька варіантів вирішення тої чи іншої задачі та пропонує найоптимальніший з них, зваживши всі плюси й мінуси реалізацій. Розробники не завжди мають достатню широту знань, щоб вибирати з-поміж кількох оптимальний шлях для досягнення мети.

Девопс має бути таким собі «цементувальним елементом» у команді, тією людиною, яка має знання різних девелоперів і інженерів якості. Мета девопса — скоротити час виходу продукту на ринок, знизити частоту відмов нових релізів, підвищити продуктивність та ефективність.

Чим займається Head of DevOps office

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

Запити від проєктів можна розділити на два види. Перший — це випадки, коли на проєкті DevOps-задачі загалом закриті й необхідні речі вже налаштовані, а сам продукт потребує мінімальних покращень чи не дуже глобальних змін. Скоупа на повноцінного девопса немає, а час на долучення нової людини до проєкту, її «розкачку» і навчання є невиправдано великим.

Або ж навпаки (другий випадок), якщо на проєкті задач стає дедалі більше і команда бачить потенціал в ефективному девелопменті, естимації та плануванні, в обізнаності з девопс-інструментами.

В обох кейсах запити, як правило, дуже конкретні і ми їх можемо закрити відносно швидко. Основне завдання — зрозуміти, які задачі в інженерів і як їм можна допомогти з навчанням, потребу, створити план і якнайшвидше взятися до його імплементації.

Одного разу був кейс, коли один з проєктів потребував підвищення рівня кваліфікації працівників в ІІS + Windows administration. Інші були зацікавлені у тому, щоб команда отримала курс і прокачування скілів з Active Directory. Треті намагались оптимізувати Jenkins CI/CD пайплайни тощо.

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

Так, менеджер проєкту може створити реквест на кшталт «отримати курси з інфраструктури як код, з конфігураційного менеджменту та оркестрації контейнерів... та й загалом по всьому», а вишенькою на торті додати коментар «і бажано в стислі терміни». Але й тоді я намагаюсь з’ясувати, які задачі ставлять менеджери перед своїми командами, і здебільшого з’ясовується, що в таких випадках обсяги робіт досить великі. Тоді ми пропонуємо повноцінного девопс-спеціаліста на проєкт.

З персональними реквестами від працівників, коли, до прикладу, спеціалісти з інших департаментів хочуть перейти у девопс-офіс, працюють дещо інші механізми. Насамперед з такими інженерами ми проводимо оцінку їхніх поточних знань, виявляємо білі плями, критичні технології чи знання, які відсутні і які необхідно закрити, щоб відповідати девопс-позиції певного рівня. Далі розробляємо план навчання. За потреби надаємо ментора, який навчає і може допомогти, коли виникають труднощі. Тоді це вже не точкове вирішення конкретної проблеми, а ціль зробити так, аби новий девопс-інженер відповідав своїй позиції за знаннями і навичками. В цій ситуації топіки, які перевіряємо, є стандартні та охоплюють:

  1. Знання операційних систем.
  2. Знання мережевих технологій.
  3. Конфігураційний менеджмент і IaC.
  4. Віртуалізація.
  5. Контейнеризація.
  6. Скриптинг.
  7. Моніторинг і логування.
  8. CI/CD.

Висновок

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

А все-таки є необхідність отримати базові скіли з DevOps-сфери для розробника незалежно від того, є на проєкті девопс чи ні.

  1. Для більш якісного і швидкого девелопменту.
  2. Для можливості побудови складних частин, які містять development i DevOps.
  3. Для кращого розуміння проєкту.
  4. Для вирішення задач різноманітними інструментами.
👍НравитсяПонравилось6
В избранноеВ избранном5
LinkedIn
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Дякую за статтю, але хотілося б прочитати не просто список DevOps технологій, а де і як ви їх конкретно застосовуєте на своїх проектах.

Дякую! Намагались дати розуміння якими інструментами варто володіти девелоперам для виконання першочергових девопс задач на проекті. Застосування їх на конкретних проектах цікава і обємна тема але вона мабуть потребує окремого топіка для кожного окремого випадка.

О, Вы уже больше пяти лет в джаве, диплом, работали зарубежом, хорошо отвечали
Стоп, у вас нет пяти лет опыта с кубернетесом?

Мы вам перезвоним

Тру стори

Спочатку компанії навішують на девелоперів, окрім власне девелопменту, ще Qa + DevOps активності, а потім дивуються, чого це на ринку пішли запити на 7-8к.

Буває, що девелопери так чи інакше стикаються з DevOps задачами. Так само є і ті хто розглядає можливість отримання секондарі скіла.

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

Воно то так і бліьш того, чим сіньйорніший розробник, тим більше його залучають в різноманітну інфраструктурно-девопсну фігню, з мого досвіду.
Хз кому як, але особисто мені цей аспект роботи не подобається.

Хз кому як, але особисто мені цей аспект роботи не подобається.

А, ну мне заходит. Да и сложно объянсить своё конкурентное преимущество иначе, если не заходит фронт).

Воно то так і бліьш того, чим сіньйорніший розробник, тим більше його залучають в різноманітну інфраструктурно-девопсну фігню, з мого досвіду.

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

задизайнить хорошее решение можно, только понимая, как всё под капотом работает.

Ну тут ми вже говоримо про рівень солюшн архітектора чи навіть інженірінг менеджера, а я все ж мав на увазі мідл-сініор девелоперів.
Само собою, архітектор має знати і бути здатним задизайнити та імплементувати не тільки архітектуру програмного рішення, а й архітектуру енвайроменту де це буде розроблятись і підтримуватись.

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

Хороший уровень кода — это уровень Strong Middle (ИМХО). Т.е., чем тогда Senior отличается от Middle? Какие задачи он может выполнить? Получается, особо никакие — что Middle, что Senior (и ещё не факт, что второй будет писать лучше код). Senior должен уже по чуть-чуть погружаться в архитектуру, и чем дальше, тем больше (собственно, Ваш пост о том, что ему всё больше приходится сталкиваться с DevOps, это косвенно подтверждает). Я миддлом вполне себе CI/CD пайплайны писал под все env’ы — при чём, там процесс был достаточно сложный из-за специфики продукта.

Хороший уровень кода — это уровень Strong Middle (ИМХО). Т.е., чем тогда Senior отличается от Middle?

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

А дрочиться с ямлами, пайплайнами и дженкинсами должен девопс, а не девелопер.

Ведь идея подкидывать девопсам таски по написанию доменной логики почему-то кажутся абсурдом, да? Тогда почему девелопер должен ковырять девопс-часть?

Так это и Senior FullStack умеет — может, даже получше за счёт ширины экспертизы. Если бэкендщик — это просто «я — илита просто потому, что лень учить ещё что-то», то смысл такого бэкендщика, если есть более универсальные и выгодные FullStack’и?) И аргументы про то, что такой бэкендщик якобы лучше знает базы/SQL к примеру, я не воспринимаю, потому что собеседований я провёл достаточно — это коррелирует скорее с олдовостью и опытом во времена отсутствия продвинутых ORM’ов, чем со специализацией. Последний человек на собеседовании, который хорошо шарил сиквел был, как ни странно, миддл фуллстек, выросший из сисадмина. Плюс Вы вроде как апеллируете, если не ошибаюсь, что и Cloud специфику знать особо не надо, потому что всё это — якобы модная блажь, что ещё один минус к бэкендовости (здесь могу ошибаться, но вроде бы так писали). В итоге смысла в таком бэкендщике 0 целых 0 десятых по сравнению с фуллстеком.

Бекендщик лучше знает API, Sql/NoSql, транзакции, работу с памятью, многопоточность, очереди, кеши, cloud, архитекруты, системный уровень. Кроме того, обычно, умеет закодить фронт без навороченых фремворков не верстая под все девайсы (внутренные тулзы с UI, как пример)
Зачем сравнивать FullStack"ов которые тебе попадались с бекендщиками которые тебе попадались и выдавать это за истину?

Почему-то не могу редактировать свой пост. Пишу еще один...
Короче уметь «девопс», это просто уметь очередной скил. Ничего из рокет сайенс в нем нету. Любой упорный дев может освоить. Спор зачем-то ушел в сторону «кто круче».
Разные компании понимают разные обязаности под одинаковыми тайтлами. Если дев должен делать опс таски, значит дев меньше времени имеет на дизайн и разработку. Если дев должен делать еще и фронтенд, значит продукт будет пилиться дольше, чем мог бы с разделением обязанностей. Но разделение требует больше людей и их менеджмента, а это уже другая проблем. Инога один человек, которые умеет всё — хорошо, иногда нет. Это зависит от продукта и стадии его развития. Людей которые действительно умеют хорошо все — немного (особенно на относительно продолжительном отрезке времени).
Почти всегда проще найти более узких спецов и менеджера. Так как их просто больше.
Некоторые компании считают, что обязаности дев и опс в одном помогают инженеру лучше ощутить проблемы продукта/клиента и более еффективно их решать.

Имхо сейчас, для успеха, инженеру нужно освоить CS и то, что требует рынок. Со временем желательно определиться со специализацией, для комфорта. А то устанешь впереди поезда бежать.

Спор зачем-то ушел в сторону «кто круче».

Он ушёл в сторону, зачем нанимать нанимать на украинском рынке человека, который знает меньше нормального фуллстека (минус фронт), и при этом именно в бэкенд углубляться не хочет, считая это работой DevOps или архитекторов.

Зачем не читать ветку дискуссии и игнорировать контекст, в котором это было написано? И зачем приходить на украинский форум со штатовской повесткой? Вы на украинском рынке давно собеседовали, или не знали/уже забыли специфику?

Зачем сравнивать FullStack"ов которые тебе попадались с бекендщиками которые тебе попадались и выдавать это за истину?

Затем, что я, видимо, получше Вас знаю украинский рынок. Зато те, с которыми сталкивались Вы, вот это истина. Предъявите сертификат тогда, что ли).

Так вот, на украинском рынке Senior разработчик в 90 процентов случаев не умеет и чаще всего даже не хочет в DevOps, и в 70 случаев на системный/Клауд уровень опуститься не в состоянии, тоже считая, что это инфраструктурщики там сами должны разбираться вместе с архитекторами. В общем, спуститесь с небес на землю).

Открой мой LinkedIn и посмотри сколько я на украинском рынке был и чем занимался. Все предположения мимо.
Перечитал дискуссию. Вроде тебе объяснили чем мидл от синьора может отличаться без уклона в опс. Ты перевел на фулстек лучше бекенда (который в твоём примере ничего не умеет).
История про бекендов которые ничего не стоят потому что не хотят делать опс притянута за уши. Украинские спецы очень даже толковые в среднем. Хотя может это с .net в Украине такая печаль?

Открой мой LinkedIn и посмотри сколько я на украинском рынке был и чем занимался. Все предположения мимо.

Смотрю: бОльшую часть времени Вы проработали на одном месте в провинциальном офисе (давайте только не будем про головной офис компании и т.д. — для нашей дискуссии это именно так), а Svitla — далеко не типичный аутсорсер/аутстаффер из-за давней remote политики в том числе (на remote нужна самоорганизация, что тянет за собой и другие позитивные для работы качества, тем самым в среднем повышая скиллсет внутри компании при прочих равных). По сути, Вы работали только в одной компании, которая нанимает специалистов по всей Украине, а я работаю уже в 4й, и это более релевантно, Вам так не кажется?

Ты перевел на фулстек лучше бекенда (который в твоём примере ничего не умеет).

Я отвечал конкретному человеку с конкретным майндсетом на конкретные аргументы.

История про бекендов которые ничего не стоят потому что не хотят делать опс притянута за уши.

Ну, конечно же, притянута). Откройте любую тему на DOU (который вроде как не форум дотнечиков), где затрагивается тема инфраструктуры, и увидите, как ситуация обстоит на самом деле. Лейтмотив всего, что не связано с кодом — «это не моя работа, отстаньте». Если по этой теме не заметно).

Разные компании понимают разные обязаности под одинаковыми тайтлами.

Совершенно верно. Но есть ещё такая штука, как позиционирование. На нашем рынке позиционирование «бэкендщик» значит, что с фронтом человек работать не хочет, а не то, что Вы написали. И если окажется, что такое позиционирование подразумевает просто отказ от фронта и больше ничего, то смысла брать такого человека особо нет при прочих равных, потому что фуллстек будет уметь то же самое + ещё фронт. Это НЕ значит, что ВСЕ бэкендщики такие, но большинство — да. И вопрос даже не в том, могут они или не могут что-то сделать теоретически, а в желании.

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

Бекендщик лучше знает API, Sql/NoSql, транзакции, работу с памятью, многопоточность, очереди, кеши, cloud, архитекруты, системный уровень

Ну вот когда Вы попытаетесь нанять Senior’ов с таким скиллсетом, тогда и поговорим (не техлидов и выше, а именно на такой тайтл с соответствующим грейдом). Потому что будете подобного кандидата полгода ждать (подсказка — он уже будет где-то работать как минимум тех. лидом). Почитайте требования к вакансиям и сами убедитесь.

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

Это опять про украинский рынок?) С каких пор у нас хоть куда-то берут за CS со смежных стеков? Говорю же, не надо путать штатовскую повестку с нашей — это два разных мира с разными правилами.

За последние три года в Украине я провел ~50 интервью и прошел около 20 сам. Все ремоут. Для меня это достаточная выборка для оценки рынка. ~70% кандидатов и интервьюверов — очень достойные специалисты. Что творится в твоей «не провинции» не могу сказать.
Повторюсь. Не стоит делать выводы о рынке, если тебе попадаются кандидаты, которые цепляют тайтл синьора и ходят на интервью. Твоя задача оценить и принять решение. Может ты просто синьоров на 2к искал?

Возвращаясь к опс теме. Те люди которые знают чего хотят — на вес золота. Если человек не хочет делать опс и может внятно это аргументировать, то для меня это признак опыта. Какой он спец покажет интервью.

Для меня вся ветка твоих ответов выше состоит из аргументов на твоих-же допущениях, самопровозглашенном авторитете и biasd выборке постов с форума.

На счет CS. Если кандидат хорошо ориентируется в структурах данных, может оценить сложность операций по времени и памяти, может обяснить на каких примитивах построены технологии с которыми он работал, то это хороший признак того, что кандидат ориентируется в CS. Не обязательно давать алго задачку, дизайн или математику. Так вот, 90% «галер» спрашивают структуры данных и внутренности технологий. За это и нанимают, в том числе.

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

~70% кандидатов — очень достойные специалисты.
...
Может ты просто синьоров на 2к искал

«Очень достойные специалисты» — это размытая формулировка. Если вы брали 70% людей на Senior позиции, впору открывать своё агентство по таким услугам — таких цифр, что 2/3 людей проходят интервью, на рынке нет даже сейчас, когда кандидатов найти — тот ещё квест. В Вашу же бытность в Свитле ситуация была очень далека от теперешней, и кандидатов +/- хватало. Ну и я знаю уровень зарплат в Свитле — такой же, как и в других больших компаниях.

Самое смешное, что именно на 2к чаще всего это и происходит, т.к. приходится снижать требования и брать всех подряд).

Про интервьюеров — само собой, что у интервьюеров будет хороший уровень — они-то здесь при чём.

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

При этом свои допущения, основанные на меньшей выборке, провозглашаются аргументом. Ок, так и запишем: «моё кунг-фу лучше, чем твоё кунг-фу», «я считаю иначе — значит, ты biased». Действительно, нет смысла продолжать с таким уровнем аргументации).

На счет CS. Если кандидат хорошо ориентируется в структурах данных, может оценить сложность операций по времени и памяти, может обяснить на каких примитивах построены технологии с которыми он работал, то это хороший признак того, что кандидат ориентируется в CS. Не обязательно давать алго задачку, дизайн или математику. Так вот, 90% «галер» спрашивают структуры данных и внутренности технологий. За это и нанимают, в том числе.

Манипуляция. Нанимают «за это» и «за это в том числе» — разные вещи. С CS без релевантных технологий в Украине Вас не возьмут ни-ку-да. Точка. И в Свитлу бы не взяли). Исключений будет мало настолько, что ими можно пренебречь (я за почти 8 лет работы видел аж 1 такую вакансию с достойной компенсацией). Тем более, что CS на галерах чаще всего спрашивают на достаточно поверхностном уровне — здесь могу подтвердить, что это редко вызывает проблемы (и при этом же я не утверждаю, что такой подход с CS — это плохо, ибо, опять же, украинский рынок диктует свою специфику). Поэтому про CS — полностью мимо, рынок не тот.

ще Qa + DevOps активності, а потім дивуються, чого це на ринку пішли запити на 7-8к.

В отличии от коденья, девопсятина осваивается с полпинка. Скажем, что-то типа недели мне хватило — чтобы с нуля, поставить на Hyper-V виндовый сервер (для домен-контроллера/юзеров, ремоут-доступа), ещё оду винду для ТФС + несколько винд для удалённых клиентов, сделать из этого всего внутреннюю сетку.
+ вывести сервак через файрволлы наружу и прописать в днс сайта (хостящегося в совсем другом месте), для удалённого доступа юзеров по чём-то типа «дев.фирма.ком».

А всякие дженкинсы, нгингсы с хостами, итп — поднимаются за пару часов. Достаточно гуглы и прочую доку читать и понимать прочитанное.

Так что, пускай навешивают. :)

Гигант наклацать кнопочки в винде, или apt-get install? :)

Нет! Это эталонное проявление эффекта Да́ннинга — Крю́гера, достойное занесения в учебники

Какова вероятность, что на проекте нужно будет именно разворачивать с нуля вот это все, а не разбираться, почему что-то не так работает, как ожидалось.

Всегда нужно быть готовым к тому, что тебе просто пришлют aws_credentials.csv и дадут три дня месяц времени на все :)

Та да, 2 месяца мануалы почитать и можно на senior devops подаваться=)

так это ты «одминство» освоил

Особливо по кайфу колупатися день-два-тиждень з джобами на CI, підкручувати скрипти і визначати що там заекспайрилося чи де змінився шлях до одного з файлів чи чого версії не апдейтнулися.
Робота мрії просто)

Выглядит как проблема версионирования пайплайнов либо устаревшего инструментария — если код пайплайна лежит в репо там где и код, который он билдит то это все можно делать чуть ли не автоматом и build gates не дадут смерджить новый код пока пайплайн не будет рабочим.

Іноді, СІ по якійсь причині вимикають( як правило, через тести, які не проходять, тому що змінилися реквайременти і самі тести треба фіксати або їх банально давно не апдейтили), білдається, тестується, деплоїться вручну, тому що так швидше ніж все фіксати. Бачив таке купу разів, особливо, в том аутсорсерах.
І в один момент хтось із менеджменту чи замовник доходить до думки, що це треба вертати і фіксати і ось тут починається найцікавіше.

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

Подписаться на комментарии