В компаниях работают разные люди, и для «эпизодического» пользователя SCM или того кто переходит с SVN важны вот эти все мелкие детали. Веб-дизайнеру или сисамдину, который работает с репозитарием раз в месяц, реально либо использовать GUI, либо начать с чего-то концептуально простого. Сетевая шара, Drpobox — понятно. SVN — на уровень сложнее. Mercurial — почти космос. Git — космос.

Они не глупые, просто оно им не нужно, как vi.

Главное — фундаментальные скилы в программировании на любом языке, алгоритмы и упражнения, чтобы человек был в принципе проф. пригоден к этому. Плюс опытный пользователь РС.

Далее:
— элементарные основы БД + SQL (куча онлайн-туториалов, уметь написать элементарный запрос на выборку/обновление)
— HTML (структура, XPath, CSS-селекторы — тут наверное больше всего)
— теория тестирования (куча информации онлайн)
— любой курс по автоматизации тестирования с практическими упражнениями

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

Вариант — «Developer in Test». Позиционировать себя как начинающего разработчика, который готов заниматься автоматизацией тестов.

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

ДевОпс в последнее время значит что угодно, обычно «мы так назвали сисадминов, чтобы круче звучало и проще людей искать».

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

Да не будут никогда админы апдейтить инфраструктуру раз в две недели.

Что админам бизнес скажет, то они и будут делать. Это как «да не будут разработчики никогда писать тесты».

Windows XP и FoxPro — зрелый софт, ок.

Банкоматы — устройства с кучей ограничений и небольшим набором функций. К внутреннему софту относятся как к «прошивке» в роутере или игровой приставке. Используют, пока не отработает свою стоимость.

Сравните с современными банкоматами: тач-скрины, миллион функций, постоянные обновления. Это ж всё дополнительная прибыль. Делают, когда железо позволяет.

Очень даже осмысленен и полезен. Continuous delivery снижает риски, повышает качество и убирает потери по всей цепочке от постановки требований до конечного пользователя. Вопрос только в том, насколько это оправдано финансово в конкретном случае: нужно вложиться в простроение процессов и автоматизацию.

Через несколко лет будет такой же мейнстрим, как сейчас Continuous Integration и DevOps. Есть куча видео и литературы, рекомендую запрыгивать в поезд ;)

А с Google Chrome что не так?

Никто не говорил что continuous delivery это просто.

С внутренним заказчиком видел только одну явную проблему: поначалу тяжело сдерживать бизнес от глобального изменения приоритетов по ходу итерации. Со временем привыкают и начинают ценить предсказуемость и повторяемость.

А что не так с долгосрочными проектами? Насколько долгосрочные?

Лайфхак насчет упёртых кастомеров и овертаймов. Спросить: «А если не через полгода, а через неделю, но только одна фича из 10-ти?». Работает like magic.

Дальше дело техники — построить процесс, который позволяет часто релизиться!