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

Мне жаль что вы в такой среде работаете

а реальное творчество у менеджеров - именно они решают, каким будет продукт

я ушел из нее, и жизнь моя заиграла новыми красками.

Чег ои вам желаю.

а реальное творчество у менеджеров - именно они решают, каким будет продукт

нет.

творчество и работа триггером, которые поворачивает поток туды сюды это разные вещи.

да, эта механика формирует результат. но называть ее творчеством - увы нет.

ну, а творчества в отрыве от денег в компаниях нет

цель бизнеса - заработать деньги

пусть зарабатывает.

придумать, как удовлетворить потребность клиента, как сделать новый крутой продукт, полезный людям или создать новый рынок - разве это не творчество?..

тут много таких моментов может быть у менеджеров

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

в этой цепочки именно у менеджмента больше всего возможностей для творчества и самореализации в рамках рабочего процесса

инвесторы/владельцы - они сосредоточены на повышении стоимости компании, там отчёты и прочее такое, напрямую они практически не влияют на продукт, а смотрят на него "из зала"

а исполнители, наоборот, у них нет полномочий чтобы что-то менять в продукте важное

придумать, как удовлетворить потребность клиента, как сделать новый крутой продукт, полезный людям или создать новый рынок - разве это не творчество?..

А теперь ответьте себе а вопрос, сколько из всех менеджеров занимаются этим а не тупым микроменджементом, и раздачей указаний типа "сделать заебись"

микроменеджмент - это зло

нужно уметь делегировать процессы ответственным исполнителям

да, не все умеют

в России

у нас часто подход "я начальник - ты дурак"

микроменеджмент - это зло

А есть ещё чайка менеджмент. Пришёл пооорал, ушёл.

😄😄

Парни, вы бы лучше вместо этих бесполезных разговоров, почитали про Kubernetes, Mesos, DC/OS.

Денис, согласен, это более конструктивно.. меня довольно легко спровоцировать на флуд - моя слабость :-)

И так, кто пробовал gitlab ci?

йа

Я запустил 3 проекта на нем после Jankins - и я в него влюбился

Настройка из файла проекта - круто

ssh агент в проектах не нужен ?

Правда с воркерами придется работать только в интрасети - не безопасно

Смотря для чего

для деплоя там или еще чего

я не нашел нормального варианта как его подсунуть

тот который у них на сайте - фуфло.

деплою через ssh

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

Дык! Опять же у нас свой инстанс gitlab

в Интра сети

и это никак не снимает того факта что их надо оберегать

а что слоэного?

да не сложно. просто хотелось бы что бы серкретные перменные были секретными :)

а как ты их сделаешь сикретными, когда можно написать любой скрипт выполнения и прокинуть результат в консоль?

никак

либо отделять CI жестко

чтобы log был не доступен прогеарм

*прогерам

нет

я бы на уровне воркера искал в выводе секретные пемеренные

и заменял бы из свездочками

перед отправкой на координатор

ли на координаторе искал в ввыоде их же

ла дално

искать и заменять это очень сложная вещь

и легко обойти

преобразованием

да но это всё лучше.

так что проще просто на уровне интеряейса gitlab закрыть доступ к ресурсу лога

а мне нравится отсуствуие возможности "параметризировать" билд из коробки, а не через вызов хука с параметрами

кстати, Павел а ты не проверял пулреквесты ?

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

проверял? в смысле?

мне вот интересно пулрексесы будут проверятся с какими перемнными окружения ?

с каим поставишь

из контекста исходящего проекта или принимающего

если я вот сделать fork а потом хочу мердж

и не получится ли ситуация при которой я делаю форк, правлю gitlab-ci.yml нf предмет добавления env|sort и отправляю пулл реквест :)

форк это же отдельный проект

так

значит секюрные переменные надо для него задать свои

соврешенно естественно что при коммите я должен буду прогнать по своему проекту ci

при мерже принимающий видит изменения в gitlab ci

но при мерже соврешенно логично что с целевым

а изменить среду можно как раз переменными окружения

так что менять gitlab ci совершенно не нужно

нужно его написать один раз нормально и забыть

А вот в дженкинсе можно создать password переменную, и в логах ее видно не будет

Да, это плюс