Счастлив тот разработчик, где разрабатываемое приложение можно полностью завернуть локально в эмуляторы или классы-заглушки)
Статья интересная, добавлю только что прописывать контейнеры на уровне кода можно, но нежелательно.
Лучшая практика для сложных систем - запускать локальные тесты в контейнере с базой которая является дампом с боевого бекапа.
Иметь скрипты что проверяют базу на валидность, то есть вы прогнали тесты а потом проверили саму базу - не сломало ли где-то поле или еще что то
В идеале (если это что то что прокидывается через интернет) делать подключения к тестовым средам через контейнер который может эмулировать перебои с сетью, шакалить пакеты и тд
У меня есть опыт с реальным банковским серверным приложением и кроме всей криптографии прочего (что успешно завернулось в контейнеры для тестирования) есть еще физические устройства (как serial так и просто input/output) и там только живые тесты руками с реальными устройствами((
как же блин такое бесит, особенно если в разном софте считают "занимаемое место" по своему. пишут что надо 10Гб свободного места, проверяешь что есть как раз свободное в притык, а ему собака надо 10+ причем практически 11ГБ
следуший уровень это говнопровайдеры которые считают скорость и потраченые гигабайты так как им удобно
ага, и все поддерживаемые платформы до 2022 с ооочень редкими исключениями.
причем "свежие" платформы что то с чем то - чет сомнительно что проект развивается.
я сам противник того пиздеца что гугл сотворил с андроидом и потому блокировки и рут наше все но тут сомнения в том плане что оно поддерживается - гугл воюет с обходами постоянно и потому лучше простой рут с фаерволами и тд, чем вот такое что может внезапно отпасть (приложения) и восстановление будет не скоро и вообще будет ли
я далек от ядерных реакторов, но много знаю про промышленную автоматизацию, особенно в больших критических узлах
если автоматика то всегда есть ручной режим, всегда. то есть можно рубануть рубильник и руками все переключить.
если система критичная то программная автоматика дублируется механической. механика идет по верхнему пределу и в теории если с программной все ок не будет задействована но она расчитана на реагирование аварийности, то есть в случае с реактором 100% есть механические размыкатели, что отпускают стержни если температура поднялась выше предела например (таким системам столетие, они простые как двери и для связи требуют только термотрубку)
все пиздецки сложные системы автоматизации в критическом сегменте обязаны иметь "резервный контур управления" на чистой механике, то есть релейках и прочих аналоговых устройствах. не весь функционал, но самый критичный. это нужно как для замены/обслуживания контроллера так и как еще один уровень защиты в случае если с контроллером что то не то.
Счастлив тот разработчик, где разрабатываемое приложение можно полностью завернуть локально в эмуляторы или классы-заглушки)
Статья интересная, добавлю только что прописывать контейнеры на уровне кода можно, но нежелательно.
Лучшая практика для сложных систем - запускать локальные тесты в контейнере с базой которая является дампом с боевого бекапа.
Иметь скрипты что проверяют базу на валидность, то есть вы прогнали тесты а потом проверили саму базу - не сломало ли где-то поле или еще что то
В идеале (если это что то что прокидывается через интернет) делать подключения к тестовым средам через контейнер который может эмулировать перебои с сетью, шакалить пакеты и тд
У меня есть опыт с реальным банковским серверным приложением и кроме всей криптографии прочего (что успешно завернулось в контейнеры для тестирования) есть еще физические устройства (как serial так и просто input/output) и там только живые тесты руками с реальными устройствами((
кто ж так таблицы составляет?
тема интересная, но читать мозги сломать можно, и полей можно добавить, а то как то все вперемешку
как же блин такое бесит, особенно если в разном софте считают "занимаемое место" по своему.
пишут что надо 10Гб свободного места, проверяешь что есть как раз свободное в притык, а ему собака надо 10+ причем практически 11ГБ
следуший уровень это говнопровайдеры которые считают скорость и потраченые гигабайты так как им удобно
ага, и все поддерживаемые платформы до 2022 с ооочень редкими исключениями.
причем "свежие" платформы что то с чем то - чет сомнительно что проект развивается.
я сам противник того пиздеца что гугл сотворил с андроидом и потому блокировки и рут наше все но тут сомнения в том плане что оно поддерживается - гугл воюет с обходами постоянно и потому лучше простой рут с фаерволами и тд, чем вот такое что может внезапно отпасть (приложения) и восстановление будет не скоро и вообще будет ли
я далек от ядерных реакторов, но много знаю про промышленную автоматизацию, особенно в больших критических узлах
если автоматика то всегда есть ручной режим, всегда. то есть можно рубануть рубильник и руками все переключить.
если система критичная то программная автоматика дублируется механической. механика идет по верхнему пределу и в теории если с программной все ок не будет задействована но она расчитана на реагирование аварийности, то есть в случае с реактором 100% есть механические размыкатели, что отпускают стержни если температура поднялась выше предела например (таким системам столетие, они простые как двери и для связи требуют только термотрубку)
все пиздецки сложные системы автоматизации в критическом сегменте обязаны иметь "резервный контур управления" на чистой механике, то есть релейках и прочих аналоговых устройствах. не весь функционал, но самый критичный. это нужно как для замены/обслуживания контроллера так и как еще один уровень защиты в случае если с контроллером что то не то.