Есть такая категория людей, которые умеют сделать такое криворукое решение, что потом иначе как по кривому его поддерживать не получится...
Ну не об этом. У нас есть раболчий процесс, который состоит из множества действий, условий окончания, подвязано множество людей, выполняется в среднем за 2-5 дней. Процесс прикручен к типу контента, на основе которого в итоге получаются библиотеки документов. Процесс используется в работе более чем 200 людьми, постоянно в запущенном состоянии находится более 100 таких процессов.
И тут всплывает криворукость, даже хуже, вылезает просто тупой баг - в одном месте (да ладно уж, везде) разработчики забыли проверить переменную на null. Это всё рушит в 10% случаев. 10% - это то число библиотек, где забыли включить обязательное заполнение поля, поле остаётся null, а оно в коде используется...
Что делать-то? Остановить все рабочие процессы, исправить и запустить заново с потерей состояния? Исправить в этих 10% списков требования к полю и забыть это сделать в следующие сто раз?
Криворукий код и подход к разработке не дают сделать по простому - сделать новую сборку и провести апгрейд - всё молча рушится.
Как ни странно, но в этой ситуации нам на помощь приходит Sharepoint, который (опять как ни странно) рассчитан даже на самое тупое использование - можно в GAC удалить dll с кодом и вставить новую, перезагрузить пул веб-приложения. Все запущенные рабочие процессы продолжат работать по старому сценарию, даже после перезагрузки, а новые будут по новому рабочему процессу. Данные о рабочем процессе, логике и т.п. сохраняются всегда для каждого элемента. Странно... но логично.
Комментариев нет:
Отправить комментарий