Но бывают моменты, когда нужно быстро (пока не забыл) создать задачу, а потом уже доописать, найдя ее, допустим, по названию. Или из списка быстро создать.
Практическая польза тут скорее в самом прототипе, на который, подумав, можно ещё что-нибудь нужное накрутить.
Иван, спасибо за информативную статью и интересную манеру подачи. Есть вопрос. Вот настроили задания на срабатывание на ветке staging. Получается, при создании merge request сработает наш пайплайн: сбилдит, протестит и развернет. Но сделает он это всё, насколько я понимаю мануалы GitLab, во-первых, ДО апрува и мержа, во-вторых, на вливаемой ветке (т.е. ветке фичи). Вопрос, что делать, если хочется собирать, тестировать и разворачивать результат мержа в ветку staging? Т.е. чтобы пайплайн срабатывал в момент нажатия кнопки Merge.
никто не сталкивался, что при переходе на сабжевую версию merge request'ы теперь делаются не из ветки фичи, а из целевой (в мое случае develop)? Получается, что не изменения из ветки фичи вливаются, а создается копия моих изменений, но уже в целевой ветки. Соответственно. в дереве это отображается как тупиковая ветка фичи и изменения из ниоткуда в develop
Мне кажется, вываливать сумму премий в открытый доступ — плохая идея. Дружный коллектив мгновенно начинает звереть, обстановка в компании становится нездоровой.
А так, идея с «акциями» неплохая, конечно
У руководителей как раз постоянно меняется фокус. Поэтому автоматизировать весь процесс подготовки отчёта невозможно. Я уже молчу про то, что обычно голых цифр мало — нужен комментарий, почему показатели поменялись и в целом что происходит на рынке, т.е. грамотный текст, написанный аналитиком
Я привык пользоваться Домодедово, но недавно воспользовался и сабжем. Внутри действительно просторно и спокойно, но всё впечатление от аэропорта портит сложный подъезд на машине: 2/3 дороги занято бомбилами на авароийке, на территории несколько парковок с радикально разными тарифами, часть их них закрыта, либо заполнена. Куда ехать, непонятно. В итоге пришлось остановиться на полосе kiss & ride, попрощаться и через taxilane с несущимися маршрутками перейти непосредственно в аэропорт.
А к автору вопрос: почему не все виды транспорта освещены, Мне, например, гипотетически было бы удобно добираться электричкой, которая едет с остановками, но она следует до старой платформы Аэропорт, которая находится хрен знает где.
В мобильном приложении данные хранятся и подставляются автоматически. Правда, потом геморрой: нужно через приложение скачать на телефон извещения, запихнуть их в Дропбокс (или передать другим способом на комп), и с компа уже распечатать.
Согласен, не всегда удобно
Но бывают моменты, когда нужно быстро (пока не забыл) создать задачу, а потом уже доописать, найдя ее, допустим, по названию. Или из списка быстро создать.
Практическая польза тут скорее в самом прототипе, на который, подумав, можно ещё что-нибудь нужное накрутить.
Для меня наиболее удобным было старое приложение почившего Рокетбанка (без Х). Всё было в нём удобным и рядом
Иван, спасибо за информативную статью и интересную манеру подачи. Есть вопрос. Вот настроили задания на срабатывание на ветке staging. Получается, при создании merge request сработает наш пайплайн: сбилдит, протестит и развернет. Но сделает он это всё, насколько я понимаю мануалы GitLab, во-первых, ДО апрува и мержа, во-вторых, на вливаемой ветке (т.е. ветке фичи). Вопрос, что делать, если хочется собирать, тестировать и разворачивать результат мержа в ветку staging? Т.е. чтобы пайплайн срабатывал в момент нажатия кнопки Merge.
А так, идея с «акциями» неплохая, конечно
А к автору вопрос: почему не все виды транспорта освещены, Мне, например, гипотетически было бы удобно добираться электричкой, которая едет с остановками, но она следует до старой платформы Аэропорт, которая находится хрен знает где.
Имел в виду знакомых с C#, но незнакомых с F#
Спасибо
Спасибо