Нежелание погружаться было всегда и никуда оно не денется, но меня немного напряг наезд про то что CI/CD это какие-то там инструменты.
Не в том плане что не нужно разбираться какую задачу они решают и как, сколько о том сколько этих инструментов существуют и насколько по разному решают проблемы.
Я сам не DevOps, а фронт, но за свои 10 лет работы фронтом я очень много раз занимался DevOps делами, потому что DevOps-ов всегда меньше чем нужно или вовсе нет.
И каждый раз приходя на новую работу я вижу новую балалайку. То там TeamCity со своим Kotlin, то Jenkins со своим Groovey, то Gitlab CI с Shell, то Bamboo. И ладно бы просто разные платформы, но одна суть, но нет. Каждый раз ты приходишь на проект и видишь очередное решение той же задачи только новым способом.
И в этом плане я больше буду рад если DevOps внедрит готовый, понятный инструмент, использует готовый подход и решение, даже если оно чуть-чуть менее эффективно.
Зато поддержка этого будет простой, я как фронт легко туда залезу и все подправлю, и не буду вынужден знать всех тонкостей этого DevOps мира
Потому что сегодня вы все настроили, оно собирается, а завтра оно взорвалось и копать это будет либо другой DevOps, а скорее всего кто-то из разрабов и там все должно быть тупо и легко гуглиться.
Какое-то непонятное сравнение…
Вроде бы Django это фреймвор на Python, и Express это фреймворк на node.js.
Но сравнивая вы берете репозиторий node.js и говорите что у него больше звезд, хотя если взять репозиторий express, что кажется логичнее, то звезд у него будет примерно столько же.
Про него не слышал. Пробовал многие другие генераторы, попробую разобраться с ним, спасибо. Но подозреваю что с ним будут такие же проблемы как с другими очень общими решениями — долгая настройка. Я в своем решении пытался сделать что-то на подобии plug-n-play.
Я пробовал его. Многие подобные инструменты в целом достаточно гибкие, но все равно не покрывают всех фич которые я хотел реализовать. Или делаются достаточно сложно.
Одной из целей своего CLI я закладывал также возможность настройки его для проекта за очень короткое время. А с plop это хоть и можно сделать, но нужно так хорошенько посидеть, почитать документацию и написать код со всеми этими prompt-ами и прочим.
Кроме того, я пытался закрыть также боль с выбором места размещения компонента. Когда у тебя компонент лежит очень глубоко крайне сложно прописывать путь даже с авто-подстановками. В своем CLI я сфокусировался на быстром поиске нужной папки в интерактивном режиме. Вы можете попробовать, например папку FileModal вы можете найти просто вбив FM и нажать энтер. Скорее всего и через plop можно такое сделать, но это потребует множества усилий, а тут все это идет из коробки.
Я хочу как-нибудь попробовать разобраться во всех существующих популярных кодогенераторах и замерить сколько по времени я буду их настраивать для собственных нужд с нуля.
Information
Rating
Does not participate
Location
Санкт-Петербург, Санкт-Петербург и область, Россия
Ну DevOps как инженеры решают задачу, но к сожалению, специалистов не достаточно для того чтобы эти решения еще и поддерживать круглосуточно.
Поэтому основу закладываются DevOps-ы, а поддерживают все это безобразие когда-то они же, а когда-то и разрабы
Нежелание погружаться было всегда и никуда оно не денется, но меня немного напряг наезд про то что CI/CD это какие-то там инструменты.
Не в том плане что не нужно разбираться какую задачу они решают и как, сколько о том сколько этих инструментов существуют и насколько по разному решают проблемы.
Я сам не DevOps, а фронт, но за свои 10 лет работы фронтом я очень много раз занимался DevOps делами, потому что DevOps-ов всегда меньше чем нужно или вовсе нет.
И каждый раз приходя на новую работу я вижу новую балалайку. То там TeamCity со своим Kotlin, то Jenkins со своим Groovey, то Gitlab CI с Shell, то Bamboo. И ладно бы просто разные платформы, но одна суть, но нет. Каждый раз ты приходишь на проект и видишь очередное решение той же задачи только новым способом.
И в этом плане я больше буду рад если DevOps внедрит готовый, понятный инструмент, использует готовый подход и решение, даже если оно чуть-чуть менее эффективно.
Зато поддержка этого будет простой, я как фронт легко туда залезу и все подправлю, и не буду вынужден знать всех тонкостей этого DevOps мира
Потому что сегодня вы все настроили, оно собирается, а завтра оно взорвалось и копать это будет либо другой DevOps, а скорее всего кто-то из разрабов и там все должно быть тупо и легко гуглиться.
Вроде бы Django это фреймвор на Python, и Express это фреймворк на node.js.
Но сравнивая вы берете репозиторий node.js и говорите что у него больше звезд, хотя если взять репозиторий express, что кажется логичнее, то звезд у него будет примерно столько же.
Одной из целей своего CLI я закладывал также возможность настройки его для проекта за очень короткое время. А с plop это хоть и можно сделать, но нужно так хорошенько посидеть, почитать документацию и написать код со всеми этими prompt-ами и прочим.
Кроме того, я пытался закрыть также боль с выбором места размещения компонента. Когда у тебя компонент лежит очень глубоко крайне сложно прописывать путь даже с авто-подстановками. В своем CLI я сфокусировался на быстром поиске нужной папки в интерактивном режиме. Вы можете попробовать, например папку FileModal вы можете найти просто вбив FM и нажать энтер. Скорее всего и через plop можно такое сделать, но это потребует множества усилий, а тут все это идет из коробки.
Я хочу как-нибудь попробовать разобраться во всех существующих популярных кодогенераторах и замерить сколько по времени я буду их настраивать для собственных нужд с нуля.