LINUX.ORG.RU

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

 , , , ,


0

4

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

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

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

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


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

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

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

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

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

Завести скриптик который делает 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 ★★
()
Ответ на: комментарий от ya-betmen

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Toxo2 ★★★★
()

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

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

ugoday ★★★★★
()

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

max_lapshin ★★★★★
()