Слева на право: джун, мидл и сениор
16.09.2021, 22:46
Он в удаве
Ммм... Vore!
Тимлид в трелло таблички делает. Не мешай ему
В действительности нет ничего страшного в тестировании на проде если просчитываешь риски - то есть насколько быстро сможешь поправить или откатить.
К тому же тут чисто экономический вопрос - фиг ты у начальства выпросишь средств на полноценный тестовый сервер + тестирование увеличивает сроки выпуска доработок, что не нравится заказчику.
Так что получается если ты долго шлифуешь продукт и не выпускаешь его - в глазах начальника ты лентяй и прожираешь зп за зря, а если после публикации на проде случилась ошибка и ты ее быстро поправил, то в глазах начальника ты молодец-удалец и вообще на тебе вся фирма держится.
К тому же тут чисто экономический вопрос - фиг ты у начальства выпросишь средств на полноценный тестовый сервер + тестирование увеличивает сроки выпуска доработок, что не нравится заказчику.
Так что получается если ты долго шлифуешь продукт и не выпускаешь его - в глазах начальника ты лентяй и прожираешь зп за зря, а если после публикации на проде случилась ошибка и ты ее быстро поправил, то в глазах начальника ты молодец-удалец и вообще на тебе вся фирма держится.
Я даже специально выкладывал с багами и недоработками, чтобы проверить, что на мою работу людям не похуй. В случае, если не похуй - оперативно фиксишь (и ты молодец), а если похуй - ну похуй, так похуй. Может быть, когда-нибудь руки дойдут.
Разумеется, речь не про критические и ломающие всю работу баги.
Разумеется, речь не про критические и ломающие всю работу баги.
Хех, почитал. Оказывается, я сам того не зная, его когда-то использовал.
Публиковал обновления на одном из серверов из 33, и никому, кроме поддержки не говорил. В случае, когда тестировщикам не веришь, а изменения серьезные. Только важно не говорить пользователям о том, что могут быть баги, потому что они начинаю собирать и столетние баги, и то, что вообще багами не является.
Публиковал обновления на одном из серверов из 33, и никому, кроме поддержки не говорил. В случае, когда тестировщикам не веришь, а изменения серьезные. Только важно не говорить пользователям о том, что могут быть баги, потому что они начинаю собирать и столетние баги, и то, что вообще багами не является.
С тестовыми серверами в моей предыдущей конторе начальство решало таким способом: у почти всех айтишников (не только разрабов, но и тестеров, дезигнеров и даже суппорт не избежал участи) в коллективе на машине поставили виртуалбокс или гипер-в (у кого что), там крутилась тестовая ось, на которой дженкинсом запускались тесты. Предполагалось что виртуалка в фоне будет не сильно тормозить людям машину, а мы получим несколько десятков тестовых ранеров не вкладывась в железо. Не то чтобы руководство зажимало деньги на железо, но просто кое у кого в жопе играло оптимизаторство и рационализаторство. А настраивать и поддерживать это всё пришлось мне. В итоге выяснилось что одновременный запуск на десятке машин разом npm install умудряется сожрать все иопсы на диске (хотя вне виртуалки норм) и положить нахер гигабитную локальную сеть. Нагрузочное тестирование просто пошло нахер в полном составе тестов т.к. таймауты и прочие тайминги на каждый запуск отличались раза в два а то и в три. Также народ вообще не следил за тем крутятся ли у него тесты сейчас или нет, и бывало просто закрывал крышку ноута (или просто выключал комп и для домой), ноут засыпал, виртуалка тоже, а у дженкинса отваливался тест по таймаутам, и кое кому (не буду показывать на себя кому) начинали сыпаться красные письма с ошибками, мол беги разбирайся. Короче было не скучно
npm скачивал свою репу. там очень много (десятки тысяч) мелких файликов. несколько категорий тестов запускались на каждый коммит, и перед каждым запуском всё очищалось от предыдущего прогона, и скачивалось с нуля. хрен его знает чо там падало, но мне пришлось заниматься оптимизацией этого момента. вначале поставили локальный кеш npm-а на сервер, и качали с него, помогло, но серверу плохело (он тоже крутился на виртуалке и ей много ресурсов не дали), начали ставить самые жирные пакеты в глобал, потом и это чем-то не угодило, не помню уже чем. короче там прохладых историй целая серия, а мне влом
Два конца сетевого кабеля в один коммутатор и если он простой или не настроен - сеть ляжет.
именно этой работой я и занимался. половина вложенного в создание системы труда была моей. тестовые машины то у нас тоже были, но тестов много, некоторые из них, например интеграционные и нагрузочные могли идти заметно долго, а начальству хотелось результатов на каждый коммит, чтобы всякие там регрессии замечать, красивые графики рисовать и т.д. потому очередь на запуск на тестовые машины, в особо сложных случаях, могла растягиваться до утра следующего рабочего дня. проблему попытались решить экстенсивно, увеличив количество тестовых ранеров. не скажу что всё было в дерьме или в шоколаде, но спустя пару месяцев оно таки более-менее приемлемо заработало.
> нет ничего страшного в тестировании на проде если просчитываешь риски
Знаменитые слова создателей ПО Boeing 737 MAX
Знаменитые слова создателей ПО Boeing 737 MAX
Depends. Я видел достаточно много проектов где команда разработки решала когда будет выкатываться релиз. Конечно решения были не формата "в этом квартале пересидим, а вот в следующем как релизнемся", но вполне могли сказать заказчику "Барри, на следующей неделе релиза не будет, потому что...". Много зависит от "потому что". Я и сам уже 2 года в позиции тим лида и частенько меня слушают, если я привожу адекватные аргументы. Коммуникации-с, сэр.
По моему опыту это зависит исключительно от размеров бизнеса. В стартапах проще добазариваться (хотя там другая проблема с постоянной сменой курса из-за потенциальных инвесторов), в то время как энтерпрайзы прут напролом разъебывая все возможные процессы ради каких-то своих причин и коммуникация тут не поможет. Потому что ты пусть и лид, но представитель одного из 20 вендоров и общаешься с кем-то кто должен твою работу направлять, но сам решения не принимает. Опять же, опыт у всех разный, но я сужу и по опыту окружающих. Гребцы "контролируют" релиз ровно до тех пор пока бизнесу, условно, похуй, как только становится непохуй, твои пожелания идут нахуй, потому что бизнес платит не за хороший код и не за гениальную архитектуру, а лишь бы работало и бабки приносило.
Такие энтерпрайзы потом обычно быстро начинают понимать шо это пиздец как дорого такие релизы делать. :D Спорить не буду - у каждого свой опыт, но реально зависит от проекта. У меня сейчас заказчик, который даже на вопрос "во сколько вам встречу закинуть удобно ?" отвечает встречным "а что вы порекомендуете для нас ?" С одной стороны, очень круто, но иногда очень задрачивает что вся ответственность и реализация на твоей стороне.
Обычно у бизнеса какие-то свои мотивы KPI и прочее, кому-то нужно вчера потому что он это обещал, а то что вам никто раньше не сказал так это вы виноваты, позвонил крупный клиент и сказал, что ему нужна какая-то хуйня срочно и похуй как она там работает, она ему нужна или он уйдет к другому вендору и т.д. В конце концов релиз могу запустить вообще своими силами не уведомив вас и не посмотрев а хули там вообще в мастере лежит)
У меня есть друг который будучи контрактором с галеры практически выполняет роль СТО в стартапе и участвовал в привлечении инвестиций вместе с СЕО, его слово там практически закон, но это крайность)
У меня есть друг который будучи контрактором с галеры практически выполняет роль СТО в стартапе и участвовал в привлечении инвестиций вместе с СЕО, его слово там практически закон, но это крайность)
Чтобы написать коммент, необходимо залогиниться
