LINUX.ORG.RU

Как отделить ненужные девелоперские файлы от прода при использовании git

 , , , ,


0

4

Всем доброго дня. Нубский вопрос, но только погрузился в тему систем версионности. С самим гитом на базовом уровне разобрался, а теперь изучаю как правильно организовать с ним работу.

В общем есть проект, где кроме «боевых» файлов возникает куча сопуствующих. В данном случае не процедурный код, а ворох SQL запросов, которые потом «натягиваются» на шаблонизатор. Соответственно рядом с рабочим всегда лежит нешаблонизированный исходник, контрольный запрос типа проверить суммы без разбивки, какие-то запросы справочников посмотреть ИД и т.п. С одной стороны все эти вспомогалки тоже требуют версионности, просто заигнорить нельзя. С другой когда это разворачивается на прод через гит - туда попадает всё. Кроме того что захламляет, гипотетически и уязвимость может создать.

Как можно организовать, чтобы на прод попадали только нужные файлы? Сильно подозреваю что это вообще вопрос не к git, как раз его задача - сохранить точный (до байта) слепок ФС.

P.S. Не IT компания, варимся в собственном соку, спросить не у кого. Извините если что..


Если просто лишние файлы, то это может помочь:

git ls-files --other покажет файлы, которые не зачеканы. Их можно потом будет | xargs rm сделать.

beastie ★★★★★
()
Ответ на: комментарий от beastie

Не, я же пишу С одной стороны все эти вспомогалки тоже требуют версионности, просто заигнорить нельзя. Т.е. они тоже отслеживаются и закомичены. Или вы под «зачеканы» что-то другое имеете в виду?

«В лоб» решение конечно простое - обозначать ненужное напрмер с префиксом «_» и потом скиптом все это по маске удалять. Но это совсем примитив и на человеческий фактор завязано.

Может что-то более изящное придумали?

ewing
() автор топика
Ответ на: комментарий от ewing

Можешь завести вторую репу с игнором ненужных, на прод лить оттуда.

Но это так себе решение конечно.

sambo ★★
()
Последнее исправление: sambo (всего исправлений: 1)

А зачем хранить это всё репе продукта? Заведи другую репу для всякого такого. Ваш К.О.

no-such-file ★★★★★
()

Завести скриптик который делает tgz с нужными файлами?

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

Для плюсов и питона можно ещё написать скриптик который будет автоматом определять набор исходников.

anonymous
()
Ответ на: комментарий от HE_KOT

Ну строго говоря да. Только про суммы это чисто для примера. Плохо представляю как тестами покрыть разнородные SQL запросы, в любом случае это будет еще один файл с процедурой.

А при ковырянии в недокументированой БД зачастую бывает так что сумма в пяти местах и какой-нибудь регион в пяти местах. И никто не знает как правильно, только на уровне «бизнес сказал похоже что-то не то». Сдели по-другому. Вроде то. Через недулю выясняется что первый вариант правильный, но к нему надо добавит еще что-то. :) Так и живем.Поэтому и захотелось в версионность, надоело разбирать файлы с именами типа «суммы оттуда с добавкой численности» и «суммы отсюда без добавки»

ewing
() автор топика
Ответ на: комментарий от no-such-file

Два подряд сообщения с этой идеей. А как реализуется? Вариант сделать отдельную репу для прода а девелоперскую прикрутить как remote? Мне кажется не прокатит, git на отслеживаемые файлы gitignore не распространяет. Да и сам gitignore затрет версией из той ветки на котрую чекаутится.

Второй вариант две отдельных репы и продуктивную туда тупо копировать девелоперскую директорию кроме gitignore. Тогда да,сработает. Но как-то коряво выглядит. Для больших релизов наверное нормально. А небольшие исправления надо не забыть перекинуть. Хотфиксы только через дев-тест (ну это не страшно, у нас так и принято в целом)

ewing
() автор топика
Ответ на: комментарий от sambo

Так. Это другой подход. Сначала коммитим только то что нужно и вешаем тег например «v1-prod». А вторым коммиитом всё остальное. Разворачиваем по тегу. Вариант. Что нужное по маске можно зашить в алиас (и как оно там в гите называется) с командой add.

ewing
() автор топика
Ответ на: комментарий от ewing

Я вижу у тебя есть исходники SQL, и скомпилированные файлы. Скомпилированные файлы нужно в .gitignore и генерировать командой после каждого git pull. Исходники SQL в любом случае должны лежать так, что бы не предоставлять опасности. Лучше сконцентрируйся на этом, а не на том как в git добавить лишнюю логику.

MOPKOBKA ★★★★★
()
Последнее исправление: MOPKOBKA (всего исправлений: 1)
Ответ на: комментарий от ewing

Договариваетесь что тестовые данные храним в этой директории, шаблоны в этой, в публично доступную с веба директорию кладем только статику(css,js,картинки и вот это всё) и минимально количество исполняемых файлов(в идеале один, который по запросу сам определяет какие модули надо вызвать). Вводите процедуру code review для merge request-ов и следите за выполнением этих договоренностей.

разворачивается на прод через гит

Не забудь прикрыть доступ к .git с веба в настройках веб сервера. В идеале уйти от этой практики, конечно

cobold ★★★★★
()
Последнее исправление: cobold (всего исправлений: 1)

Можно попробовать отдельный git для доп. ресурсов и подключать через git submodule. Так в одном из проектов подключали переводы для текстов.

necromant ★★
()
Ответ на: комментарий от dataman

Бросайте git, используйте Fossil! :)

Посмотрел, запустил - блин круто! Этакий гитлаб с собой в одном файле. А какие грабли?

ewing
() автор топика
Ответ на: комментарий от dataman

Хм. На запрос «кто пользуется fossil» яндекс на первой странице выдает одну ссылку на тему с этого форума аж 2012 года Fossil и всё. остальное про часы.

А что так?

ewing
() автор топика
Ответ на: комментарий от ya-betmen

это разворачивается на прод через гит

Кажется проблема в этом, можно подробнее?

А сейчас ничего толком и нет. Есть директория с шаблонами, куда до сего момента руками нужные файлы выкладывал.

Завёл гит для версионности в первую очередь, но заодно вроде как и выкладывать через него захотелось. Типа pool мастер ветку и всё актуальное. Так делали в свой время в ML проекте. Но там был именно отдельно код и доки (через гит), а всякие модели и прочие данные отдельно передавали (что очеыидно,ибо большие, генерятся и версионность не нужна)

ewing
() автор топика

Сильно подозреваю что это вообще вопрос не к git, как раз его задача - сохранить точный (до байта) слепок ФС.

Именно так, git это не инструмент деплоя.

Как можно организовать, чтобы на прод попадали только нужные файлы?

Написать скрипт/мейкфайл/что угодно, генерирующий из исходников рабочие файлы и разворачивающий их на сервер. Вызывать из можно из хука на push, можно из CI-системы (которая заодно может протестировать получившееся перед развёртыванием)

annulen ★★★★★
()
Ответ на: комментарий от ewing

Зачем что-то куда-то копировать. Просто отдельная репа для документов, черновиков и т.п. Не для кода. Код отдельно, документы отдельно.

no-such-file ★★★★★
()
Ответ на: комментарий от no-such-file

Два чаю. Хранить все исходники в гите, учредить этап сборки, на котором из этих исходников генерируется всё, что должно быть сгегерировано, потом всё нужное для деплоя собирается в отдельный каталог/архив/образ и катится на тест/в продакшен/на раздачу.

Nervous ★★★★★
()
Последнее исправление: Nervous (всего исправлений: 1)
Ответ на: комментарий от ewing

Типа pool мастер ветку и всё актуальное.

Зойчем тебе бассейн?

Что за язык-то хоть? По идее в прод так не выкатывают.

ya-betmen ★★★★★
()
Ответ на: комментарий от Nervous

Да, для себя окончательно понял что это совсем не задача VCS системы и не надо ее сюда приплетать. Пойдем путем сборки и копирования нужного скриптом. Спасибо всем кто откликнулся!

P.S. А вариант с тегом всё таки на досуге попробую. Чисто из любопытства.

ewing
() автор топика
Ответ на: комментарий от ya-betmen

Зойчем тебе бассейн?

Купаться люблю. Только мокрыми руками печатать плохо получается :)

Что за язык-то хоть? По идее в прод так не выкатывают.

Я выше писал - не язык, а SQL запросы с расставленными метками шаблонизатора вместо параметров

ewing
() автор топика
Ответ на: комментарий от Siborgium

man git-clean

Не то. DESCRIPTION Cleans the working tree by recursively removing files that are not under version control,

ewing
() автор топика

На чем сделан прод? Как происходит деплой?

Мысль простая. Прод на линуксе с каким-то пакетным менеджером. Полезная нагрузка устанавлиается как обычный пакет и имеет свою версию и зависимости.

В гите есть «скрипт», который из содержимого репы собирает пакет. Дальше пакет инсталится в прод.

Если все это нормально обмазать автоматизацией (даже самодельной). Получишь свой наколенный CI/CD. Закоммитил в релизную ветку. По хуку собрался пакет и отправился на сервер обновлений. Оттуда прод его забрал в процессе регулярной проверки обновлений.

yax123 ★★★★★
()

Не понял что у тебя за «вспомогалки» такие что должны версионироваться но в проде не нужны. Ну сделай для них отдельный репозиторий рядом, в чём проблема?

anonymous
()
Ответ на: комментарий от anonymous

что у тебя за «вспомогалки» такие что должны версионироваться но в проде не нужны

Так тесты, наверное. Тесты, конечно, в проде не нужны.

Nervous ★★★★★
()
Последнее исправление: Nervous (всего исправлений: 1)

разворачивается на прод через гит - туда попадает всё

Дык настрой так, чтобы попадало не все. Ты же можешь в контейнеры складывать как угодно. Или как там у вас организовано?

Zhbert ★★★★★
()
Ответ на: комментарий от Nervous

Ну тесты должны быть в основной репе. Если они попадут на прод то ничего страшного не случится. Разве что если они занимают значительный объем то может иметь смысл сэкономить и их просто не деплоить.

anonymous
()
Ответ на: комментарий от ewing

Я выше писал - не язык, а SQL запросы с расставленными метками шаблонизатора вместо параметров

Не понимаю - почему когда мешают php с html - у людей истерика и фу-фу-фу. А когда мешают SQL с Java|Python|etc - придумывают какие-то фокусы с git, но никто не плюется?

Почему нельзя оформить процедурами в БД и вообще не таскать их вместе с остальным кодом?

Toxo2 ★★★★★
()

Еще раз огромное спасибо всем откликувшимся. В какую сторону копать понятно.

ewing
() автор топика
Ответ на: комментарий от Toxo2

Может потому что процедуры в БД привязывают к конкретной СУБД, а SQL не завязанный на фичи конкретной СУБД боле-менее переносим?

sambo ★★
()

когда это разворачивается на прод через гит

Вам нужен CI/CD который будет следить за тем, что как и куда заливается на прод.

ugoday ★★★★★
()

как простой вариант — выкатка на продакшн не путем git checkout, а подготовкой какого-то пакета, который как раз идет зачищенным от предварительного кода.

max_lapshin ★★★★★
()

Ввести концепцию сборки артефакта для установки на сервер, а не копировать папку с исходниками.

vbr ★★★★★
()

Это называется sparse-checkout.

E ★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.