Меня заставила вспомнить об этом небольшая личная проблема, возникшая при работе с Web-приложением по вводу показателей домашнего электросчетчика и оплаты энергопотребления на сайте Мосэнергосбыта. Сейчас точно не вспомню, когда я начал делать это, но последние года два все работало как часы. Недавно изменился дизайн на странице авторизации, и теперь я в своем браузере FireFox просто не могу по своему паролю войти на сайт. Не то, чтобы меня не признают по учетным данным, просто при нажатии кнопки "Войти" вообще ничего не происходит (точнее, она просто не нажимается). Обратился в службу поддержки и получил "стандартный совет" - установить последнюю версию браузера, очистить кэш, куки и вообще удалить все данные. Ничего не помогло, но служба поддержки дополнительно сообщила, что они у себя проверили и в их FireFox все работает.
В чем на самом деле причина, мне трудно сказать. Возможно, возникают какие-то конфликты с установленными мной в FireFox add-ons, а может, мешает антивирус или иная программа, работающая в фоновом режиме. Но вот вопрос: как нужно вести разработку и тестирование Web-приложений, чтобы они исполнялись в любом стандартном браузере, оснащенном дополнительными расширениями функциональности? Может ли в таких условиях браузер выступать в роли универсальной среды исполнения? Ведь было бы странно, если бы разработчики рекомендовали перед использованием своей программы в обычной ОС остановить какую-то другую программу, стереть все ее данные или внести изменения в реестр. Или же будущее за автономными приложениями, не привязанными к браузеру, которыми все пользуются на мобильных устройствах (даже если у таких приложений есть HTML-редакции, работающие в среде браузера)?
Кстати, свою личную проблему я решил, так сказать, "прямым вариационным методом": попробовал зайти на их сайт в другом браузере (IE), и все прошло как по маслу. Но ведь это массовая услуга, которая рассчитана на рядовых пользователей, не знакомых с мудреными словами типа кэш и куки, а возможно, и не имеющими представления об альтернативных разновидностях браузеров.
Видимо, на разработку этих сайтов деньги выделяются, а на тестирование -- уже нет...
Не исключено, что одна из возможных причин этого печального явления кроется в том, что “Тестировщики стоят дороже разработчиков”
Организациям, которым необходимы частые выпуски программного обеспечения, может понадобиться DevOps. Дневной цикл релизов может быть гораздо более интенсивным у организаций, который выпускают несколько разнонаправленных приложений.
Методология фокусируется на стандартизации окружений разработки с целью способствования быстрому выпуску релизов. В идеале, системы автоматизации сборки и выпуска должны быть доступны всем разработчикам в любом окружении, и у разработчиков должен быть контроль над окружением, а информационно-технологическая инфраструктура должна становиться более сфокусированной на приложении.
Задача DevOps — сделать процесс разработки и поставки программного обеспечения согласованным с эксплуатацией, часто эти задачи решаются при поддержке автоматических средств.
Термин «DevOps» был популяризован серией встреч «DevOps Days», которые начали проходить в 2009 году в Бельгии. С тех пор «DevOps-дни» прошли в Индии, США, Бразилии, Австралии, Германии и Швеции.