Continuous Integration

scorpion-ds

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

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


У нас два постоянных проекта:
- один довольно старый, но постоянно дорабатывается и что-то переделывается;
- второй наш проект, сейчас активно разрабатывается.

Ни какого регламента по работе нет, есть только redmine, и у второго проекта я настроил CI Gitlab, который обновляет проект на тестовом сервере, при коммите в ветку dev.

Сейчас самая большая проблема, что все задачи идут в ветку dev, далее их тестирует тестировщик, клиенты и т.п., часть задач иногда отправляется на доработку или вовсе отменяется, потому коммитеть их все в одну ветку очень неудобно, так как потом простым путем не откатить их.

Я поставил админу, такую задачу:
- при коммите с меткой по определенному шаблону (к примеру "task-123"), создается новый хост, разворачивается копия приложения, где добавлен функционал только по одной задаче;
- при удалении такой ветки, хост и все с ним связанное удаляется;
- также существует ветка "dev" куда попадают, все что было одобрено из других веток, там тестируется взаимодействие последних обновлений, от туда со временем данные попадают на "master"

Не совсем понятно, что делать с БД, во втором проекте, есть фикстуры для тестирования, но вот как тестировать, что миграция прошла успешно, непонятно, так как на проде, кроме БД, есть очень много данных в виде файлов, разве что тестировать на фейковых данных и надеется, что на реальных все пройдет нормально.

За основу админ предложил использовать Jenkins и в целом, говорит, так сделать можно, но правильно ли так делать я не знаю, может я чего-то не учел.
 

AmdY

Пью пиво
Команда форума
а вы через гитфлоу работаете или через пулл реквесты с фичебранчами?

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

fixxxer

К.О.
Партнер клуба
@AmdY, git flow подразумевает фичебранчи, а пулреквесты вообще ортогональны - хочешь юзай, не хочешь не юзай (часто удобнее в слаке просто пнуть, скажем).

Под git flow я, разумеется, имею ввиду модель ветвления <http://nvie.com/posts/a-successful-git-branching-model/>, а не всякие хипстерские экстеншены с гуями. Ну, минус теги с semver-релизами (для веб-проектов с rolling-release это бессмысленно).

Ссылку я дал как то, что можно взять за основу, а не как руководство к копипасте.
 
Последнее редактирование:

fixxxer

К.О.
Партнер клуба
Так git flow и не навязывает именования, главное, что должны существовать production и development ветки. Production=master это просто дефолтное соглашение, не более того.
 

AmdY

Пью пиво
Команда форума
Да, мне в гитфлоу не нравятся именно реализации. Т.к. предпочитаю не делать git flow finish, а оформлять всё пуллреквестами, сквошить коммиты, оставлять старые ветки, чтобы иметь полезную историю.
 

AmdY

Пью пиво
Команда форума
ну, здесь как и с tabs vs spaces важно единообразие и чтобы не было частичных коммитов из которых не понятно что делалось в фиче.
 

fixxxer

К.О.
Партнер клуба
Ну да, у себя в локальном репозе делай что угодно, а в веточку изволь запушить так, чтобы все понятно было. Не svn же, всё для этого есть.

Вот rebase/squash-подход мне как раз не нравится тем, что провоцирует на бардак в ветке (а какая разница, типа), я считаю, что ребейзам место на локалке до пуша.
 
Сверху