Очень не обычно было работать на компанию Y. Она самая большая компания по перестрахованию юридических лиц.

Самый большой отпечаток в памяти у меня остался от рабочего day-to-day процесса. Если вы крутой разработчик, менеджер, дизайнер, архитектор и у вас рабочая машина настроена идеально для работы по специальности, то вам не повезло.

Вы будете обязаны работать через VDI (Virtual Desktop Infrastructure). Самое интересное тут то, что вы не имеете права поставить туда все, что вам нужно, только то, что одобрено СБ. Только то, что куплено компанией (лицензионное ПО). Невозможно поставить ПО, даже если вы купили лицензию официально. Весь трафик интернета просматривается и, не дай вам бог, зайти не на «те» сайты - даже разговаривать не будут. Невозможно пользовать общим буфером обмена с вашей рабочей станцией, где вы запустили VDI. А так же ваш VDI полностью виртуальный. Если вы не работали в VDI больше 3 часов или выключили, она удаляется, а создается довольно быстро, примерно 15-20 минут.

Ладно если только это было бы проблемой. Ведь качество работы с VDI служил именно интернет, а это значит, что будет пинг, что будут, определенного рода, задержки в отклике во временя работы, что приводило к искусственным задержкам в качестве производительности.

Единственный способ «общения» рабочей станции с пространством в VDI, который я нашел, это был почта. Я писал код, рисовал диаграммы, подготавливал архитектуру и документы для заказчиков на рабочей станции, упаковывал в архив и пересылал по почте.

Кстати по поводу ПО. Даже если ПО одобрено компанией заказчика, то нужно обосновать зачем оно вам нужно; и только получив одобрение вашего менеджера из full-time employees, вы его получите при следующем запуске VDI.

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

Начинал я работать с не приоритетного проекта на компанию Y. Но сам подход к безопасности меня немного раздражал и, сказать честно, пугал.

Процесс был такой. Dev и Test окружения должны быть в закрытом контуре в Azure облаке, а Prod окружение (договоренность случилась через несколько месяцев с начала работы) должно быть на on-premise пространстве заказчика.

Так вот, что бы отточить скрипты по дэплою и запуску продукта я подготавливал все стенды заранее и заливал туда «пустой» проект, что бы проверить.

Все бы ничего, но Prod стенд пришлось удалить со старого места в облаке и переместить на on-premise после того, как пришла новая договоренность.

Деплоится в Prod мы обязаны были в определенное окно времени, обычно в субботу. Расписание обговаривается не только с начальством, но и с другими командами, которых было около 15-20. Там нужно было отчитываться, кто делает релиз, что за релиз, что именно он в себя включает, с какими продуктами работает, важность релиза, версию, нужно было расписать, что будет при успешном релизе, при не успешном, нужно было расписать, каким образом мы это выяснили бы, какие этапы проверки и так далее и тому подобное.

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

При неуспешном релизе, если мы не успевали в отведенное окно, релиз откладывался на следующее окно.

И тут наступил интересный момент, которого я не ждал.

До той самой «договоренности» о Prod стенде, я проверял скрипты в облаке и пометил стенд как “prod”. А как пометил? Просто указал label/title у стенда и все :)

И ко мне в течении полугода каждые две недели приходили с расспросами, а что это? А почему вы деплоили в Prod в облаке? А кто вам дал разрешение? А почему не в релизное окно? А почему вы не создали протокол в системе с формой (что я рассказывал ранее)?

Было очень тяжело «правильно» замять эту проблему до тех пор, пока я не попросил своего начальника от заказчика это решить, расписав ситуацию, и игнорированием в последующем данных работников, работающих по скрипту и проверяющих подобные ситуации.