Не деплойте в пятницу..., или история о том, как мы 30 декабря в релиз систему запускали

В последних сообщениях я упоминал, что на работе занимаюсь разработкой некой программы. Не буду вдаваться в детали и её назначение, расскажу в целом.

Работали мы над ней вдвоем с моим одногруппником, что уже как бы намекает: ни он, ни я ни разу не сеньоры, и опыта в разработке подобных систем у нас не то чтобы много (совсем нет).

Сама по себе система довольно простая – нужно получить определенные данные из базы с условиями, вывести эти данные пользователю, дать ему возможность как-то их модифицировать, занести назад в базу и потом сгенерировать отчет в Word по определенному шаблону.

Упрощало нам жизнь то, что такая система уже существовала в виде таблицы для Excel, но работала очень медленно и очень криво, плюс разработчику, который сделал эту таблицу было совсем не до её поддержки и допиливания. Таким образом наша работа по факту заключалось в переводе всей этой штуки в формат сайта.

В качестве языка разработки был выбран язык C#, платформа – Blazor Server.

Почему так? Потому что никто из нас никогда не обмазывался всякими там Ангулярами и Реактами, а Blazor позволяет писать фронтенд прямо на C#. Ну и плюс, нашей системой не будут пользоваться миллионы человек по всему миру, а для десятка юзеров подобный стек вполне сгодится.

Итак, где-то в начале ноября мы получили ТЗ и начали работу. В процессе было много разных сложностей, куда же без них. Однако, в итоге, к концу декабря, путем уловок, компромиссов и гугления мы дошли до того, что в нормальных командах называют пре-релизом. Да, система далека от идеала, но тем не менее базовым функционалом можно пользоваться.

Не знаю кому пришла в голову идея выпустить программу в открытое тестирование перед новогодними праздниками, но мы очень старались закончить к этому сроку.

29 декабря я дописываю последнюю фичу и говорю, что мы готовы к релизу. Босс рад, и мы начинаем разворачивать систему на сервере.

Чтобы вы понимали, как мы работаем – каждый сотрудник имеет определенные права доступа ко всей инфраструктуре – интернет, сервера, базы данных. Я в этой иерархии – внизу пищевой цепочки, то есть цветочный лох, поэтому для развертывания нужно было отдать билд другому сотруднику и он уже запустил бы его на сервере. Из-за этого все дальнейшие фиксы были затруднены, так как отрывать этого сотрудника от работника – не камильфо.

Как вы поняли, с первого раза ничего не заработало. Это ожидаемо - мы работаем на ебучей винде. Сервер под названием IIS имел отключенную авторизацию средствами Windows, а на этом была завязана система прав в нашем приложении. Поэтому мы начали искать способы включить авторизацию. В целом, это не сложно и делается в пять кликов… Но оно, сука, не работало. Мы делали все по документации, но не работало.

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

На следующее утро мы вернулись к решению этой проблемы. Я решил, что будет проще не трахать сервер, а переписать авторизацию через HTTP и так и сделал, выпилив все, что было связанно с виндой. Но теперь сервер не пускает нас на сайт, потому что:

1)   В анонимном режиме не передаются данные авторизации компьютера и, поэтому при попытке получить представление пользователя мы ловим NRE.

2)   При отключении анонимного режима сервер кидает в лицо 401 ошибку, говоря о том, что у нас нет прав доступа.

Видимо, сервер очень хотел секса.

Я решил загуглить, с чем связано то, что у нас не получается включить компонент авторизации Windows. Оказалось, что мы не догадались перезапустить панель управления сервером, а без этого компонент не стартует.

СУКА. Кто так делает? Об этом ни слова в документации, да и в целом догадаться сложно – сам сервер мы перезапускали не один раз.

По итогу приложение завелось, но это не конец истории.

Оказывается, что авторизация через Винду берет имя пользователя и доменное имя компьютера, на котором запущено приложение… А ОНО У НАС СЕРВЕРНОЕ, поэтому на любом компьютере в качестве имени компьютера берется имя сервера.

Сука. Я вернулся к той версии, которая работала через Http, но там тоже самое. Оказалось, что я накосячил и не исправил момент с получением имени пользователя для вывода и всегда выводилось имя сервера.

Но и на этом все не закончилось.

Когда мы были где-то на середине разработки, я не очень хотел создавать новые таблице в базе данных, и поэтому для сохранения прогресса работы воспользовался локальной базой данных SQLite.

Именно эта база оказалась камнем преткновения – сервер упорно не хотел правильно работать с ней, то и дело ругаясь на права доступа. Ебучая винда, в том же линуксе я бы решил это дело одной командой в консоли.

В итоге, пораскинув мозгами мы решили переписать функционал с использованием основной базы. В тот момент я очень нахваливал архитектуру, которую я придумал, потому что на изменение потребовалось всего минут 20-30 с учетом фиксов всякой асинхронной шняги, которая вылезла из-за всякого рода задержек.

И вот, момент истины. Все работает.

Мы запускаем, я отправляю по внутренней почте руководство по использованию, и мы с довольными лицами идем в отдел, для которого мы разрабатывали нашу систему.

Там наша работа производит своего рода фурор – они очень довольны тем, что больше не придется заполнять все руками. И это был бы триумф… Если бы в процессе приложение не выкидывало Fatal Error при переходе на другую страницу.

Мы возвращаемся с лицом лягушки назад и говорим боссу, что обосралис. Причем, с ходу причина не очевидна – до этого мы тестили ровно по тому же пути и все было ок. Я решаю локально запустить приложение, и вижу причину ошибки – когда я переписывал таблицу с SQLite, я задал размер поля для ID сессии в 30 символов, а этот ID имеет переменную длину. На тесте нам очень «повезло», что он уместился – все остальные не влазили и были причиной ошибки.

Я редактирую таблицу, и мы возвращаемся назад. Все работает.

Мы по факту собрали комбо – задеплоили в пятницу, в канун Нового года перед длинными выходными. Конечно, это не на что не влияет и такой деплой ничем не отличается от деплоя в любой другой день, так как тот отдел имеет такой же график работы как и у нас, значит в наш выходной никто не будет использовать систему и даже если она приляжет или будет какой-то баг – никто не пострадает.

Мораль такова – пишите тесты, не деплойте в пятницу перед Новым годом, думайте, что делаете. А нам предстоит еще куча работы.

Всем спасибо, кто дочитал.