Было бы странным, если бы им не пользовались. Его как раз используют чтобы не поднимать полноценный CI сервер. Единственный минус такого решения, нужно разбираться как работает make, а это уже зависит от квалификации разработчика.
Какая разница. Изменения версии или коммита не обходится без изменения файла на диске. Этим и занимается make.
Хоть bash и есть универсальное средство, но в этой задаче он не очень подходит, так как нужно отслеживать изменения файлов и выполнять шаг только тот который необходим. А отслеживать изменения файлов прекрасно умеет make.
Да, ну? Из хука git запускается make, который из описания в Makefile проделывает эту работу: и протестирует, и по почте уведомит, и в Slack настучит, и еще кучу разных дел сделает, типа сборки дистрибутива программы. Не один раз встречал такое у разных команд и в разных проектах. Поэтому у меня возник вопрос о Makefile.
Makefile может не только собирать проект. С его помощью можно легко организовать зависимости между шагами которых нет в вашем скрипте. К примеру, не нужно запускать проект на сборку, если не изменились исходники. Тем более можно начать с любого шага и все необходимые шаги автоматом выполнятся.
Меня всегда удивляет одно: люди не пользуются какой-либо вещью, чуть-чуть попробуют ее и начинают критиковать. Сядьте и поработайте в нем с месяц другой, потом напишите статью. Два раза запустили программу — это еще не значит понимание сути того как она работает и почему именно так работает.
Согласен, что не любой. Можно и в Django такого наворотить, что скупая слеза навернется, а вот убраться и привести все в порядок в таком проекте намного легче чем на основе множества компонентов.
Еще чем лучше Django других фреймворков это предсказуемость цикла поддержки и времени жизни версии. Это для бизнеса очень веское преимущество. Ни каких революций и ломания API. Все предсказуемо, задокументировано и по плану.
Опять какой-то странный подход: взял, собрал из отдельных компонентов и сразу все производительно стало. Не бывает так. Django надо уметь готовить и уметь проектировать приложения для того чтобы достичь максимальной производительности. Она не хуже будет работать чем скопище отдельных компонентов.
Сколько раз не сталкивался с проектами основанными на множестве отдельных компонентов с Flask внутри, все болеют одной и той же проблемой
— велосипедостроительством. Как-только проект набирает массу кода, то он начинает превращаться в набор костылей с сложно отлаживаемой логикой. Переписывание проекта на Django спасает проект, и код, в этом случае, получается стандартным, в котором сможет разобраться любой нормальный программист Python.
Flask и ему подобные хороши для маленьких проектов с простой бизнес логикой, который разрабатывается командой в 2-3 человека. Где больше трех уже стоит использовать Django.
Все это испытано на своей шкуре и не на одном проекте.
Странный подход. Если будете рыть большую яму, то воспользуетесь лопатой? Нет. Воспользуетесь экскаватором. Так и в разработке, каждый фреймворк заточен под определенный класс задач.
Хоть bash и есть универсальное средство, но в этой задаче он не очень подходит, так как нужно отслеживать изменения файлов и выполнять шаг только тот который необходим. А отслеживать изменения файлов прекрасно умеет make.
В вашем случае тоже используется bash не по назначению, так как можно легко использовать любой готовый CI.
Продвинутые админы используют:
Да, конечно. Это самое разумное решение в таком споре.
Еще чем лучше Django других фреймворков это предсказуемость цикла поддержки и времени жизни версии. Это для бизнеса очень веское преимущество. Ни каких революций и ломания API. Все предсказуемо, задокументировано и по плану.
Сколько раз не сталкивался с проектами основанными на множестве отдельных компонентов с Flask внутри, все болеют одной и той же проблемой
— велосипедостроительством. Как-только проект набирает массу кода, то он начинает превращаться в набор костылей с сложно отлаживаемой логикой. Переписывание проекта на Django спасает проект, и код, в этом случае, получается стандартным, в котором сможет разобраться любой нормальный программист Python.
Flask и ему подобные хороши для маленьких проектов с простой бизнес логикой, который разрабатывается командой в 2-3 человека. Где больше трех уже стоит использовать Django.
Все это испытано на своей шкуре и не на одном проекте.
А также Лейпциг и Варна. Есть еще село Солнце. «Я живу в/на солнце» — это вполне обыденная фраза для местных жителей.
Примерно так:
Еще нужно не забыть добавить ~/bin/ в переменную PATH до основных директорий и ограничить к ней доступ.