История изменений
Исправление Iron_Bug, (текущая версия) :
это я у себя на локальном сервере могу руками что-то править, как мне вздумается. и то если на локальном. на удалённом сервере я уже тщательно подумаю о последствиях: а не отрубится ли сетка, и не потеряю ли я доступ по собственной глупости. на прод я не полезу ни за что. там работает софт, которым пользуются миллионы юзеров. если он навернётся, будет очень нехорошо всем. поэтому обычно есть админы, которые занимаются выкатыванием софта на прод, у них стоят всякие анзиблы и иже с ними, это всё делается централизованно. иногда ещё юзеров надо предупреждать, что будут технические работы, сервис будет недоступен тогда-то, столько-то времени. иногда нельзя терять данные сессий, и сессии сгружаются на винт, софт обновляется, перезапускаеся и поднимает контексты из файлов. бывает, что надо что-то поменять в БД. и тоже нужна непрерывная совместимость всего софта, потому что идёт огромный трафик, его надо обрабатывать и ничего не должно упасть. на случай факапов с обновлениями у админов обычно есть откат на предыдущую версию. но это случается крайне редко, по моим наблюдениям. хотя бэкапы и возможность быстрой реакции на нештатные ситуации должна быть. предусмотрена.
а ещё были времена, когда я писала софт для федеральных компаний: Сбер, ФТС. это была коммерческая компания, но они писали софт, в том числе, для таких крупных клиентов. у Сбера тогда своей разработки не было. и там была своя специфика: софт писался на болванки и рассылался во все отделения Сбера. издавали отдельный официальный приказ и софт обновляли везде. а машин дохрена, они все разные, от мелких деревенских отделений до крупных ЦОДов в ДС. если хоть где-то он не будет работать - это катастрофа. потому что это платежи, это обмен данными банков. то же самое с ФТС: если там бы что-то упало, то остановились бы трансграничные перевозки, «зелёные коридоры» и прочее. это было бы крайне нехорошо. поэтому дейстовать приходилось очень осторожно и всё-всё было обмазано юнит-тестами. и всё работало. нет ничего невозможного. просто надо думать головой и всё тестировать.
и есть ещё разновидность разработки под промышленную автоматизацию, в которой я тоже работала много лет. там специфика в том, что любой факап с софтом можно привести к аварийной ситуации (управление железом в риалтайме) и эти аварийные ситуации могут угрожать жизни людей (например, розлив стали на литейных производствах) или иметь довольно крупный экономический ущерб (выход из строя дорогого оборудования или испорченные материалы). иногда там были очень высокие скорости и софт должен был работать быстро (например, Гознак), иначе там бы возникали поломки и брак. так что тоже не было желания писать код плохо. это было недопустимо. и тоже всё тестировалось. в случае промышленной автоматизации для тестирования ещё и писалось окружение с эмуляцией железа, потому что гонять тесты в реальных цехах не получится.
Исходная версия Iron_Bug, :
это я у себя на локальном сервере могу руками что-то править, как мне вздумается. и то если на локальном. на удалённом сервере я уже тщательно подумаю о последствиях: а не отрубится ли сетка, и не потеряю ли я доступ по собственной глупости. на прод я не полезу ни за что. там работает софт, которым пользуются миллионы юзеров. если он навернётся, будет очень нехорошо всем. поэтому обычно есть админы, которые занимаются выкатыванием софта на прод, у них стоят всякие анзиблы и иже с ними, это всё делается централизованно. иногда ещё юзеров надо предупреждать, что будут технические работы, сервис будет недоступен тогда-то, столько-то времени. иногда нельзя терять данные сессий, и сессии сгружаются на винт, софт обновляется, перезапускаеся и поднимает контексты из файлов. бывает, что надо что-то поменять в БД. и тоже нужна непрерывная совместимость всего софта, потому что идёт огромный трафик, его надо обрабатывать и ничего не должно упасть. на случай факапов с обновлениями у админов обычно есть откат на предыдущую версию. но это случается крайне редко, по моим наблюдениям. хотя бэкапы и возможность быстрой реакции на нештатные ситуации должна быть. предусмотрена.
а ещё были времена, когда я писала софт для федеральных компаний: Сбер, ФТС. это была коммерческая компания, но они писали софт, в том числе, для таких крупных клиентов. у Сбера тогда своей разработки не было. и там была своя специфика: софт писался на болванки и рассылался во все отделения Сбера. издавали отдельный официальный приказ и софт обновляли везде. а машин дохрена, они все разные, от мелких деревенских отделений до крупных ЦОДов в ДС. если хоть где-то он не будет работать - это катастрофа. потому что это платежи, это обмен данными банков. то же самое с ФТС: если там бы что-то упало, то остановились бы трансграничные перевозки, «зелёные коридоры» и прочее. это было бы крайне нехорошо. поэтому дейстовать приходилось очень осторожно и всё-всё было обмазано юнит-тестами. и всё работало. нет ничего невозможного. просто надо думать головой и всё тестировать.