Github CI / CD / Ветвление на внешний сервер?

У нас есть репо в строгой среде разработки и частный веб-сервер, расположенный в / var / www / dev / repo . Мы хотим, чтобы все созданные ветки автоматически создавались и добавлялись в / var / www / branch / feature-coolfeature и автоматически основывались на основной ветке (или «базе на ветке»). Таким образом, мы можем очень легко загрузить в коде новую ветку в наш / var / www / dev / repo и продемонстрировать наши новые возможности ветки для клиентов и владельцев продуктов.

Представьте себе «переключатель ветвей» на нашей платформе, который будет переключаться между ветвями разработки. Кроме того, мы хотим иметь возможность делать коммиты в / var / www / branch / feature-coolfeature , как непосредственно на сервере в данной папке, так и, например, через Github Desktop.

Мы понимаем, что можем быть очень далеки от этого, и ценим любые указания относительно того, куда мы можем пойти с этим потоком, или даже попробовать совершенно другой. Пока нам удалось с помощью веб-перехватчиков Github создать структуру папок и скопировать все из исходного репозитория, за исключением того, что он не понимает, что это на самом деле ветка (думает, что это основная ветка), и мы просто видим несколько признаков того, что мы мы подходим к этой проблеме с очень и очень плохой точки зрения. Как связанные с github, так и разрешения. Мы, разработчики, пытаемся изучить DevOps.

Будем признательны за любой совет.

0
задан 6 January 2017 в 02:11
1 ответ

Ну, третье желание - это просто кусок дерьма - вы должны переосмыслить его, свой текущий и будущий рабочий процесс, чтобы не плакать в ближайшее время (я могу понять предысторию ваших потребностей, но вы должны помнить : «У каждой проблемы есть хотя бы одно очевидное , простое и НЕПРАВИЛЬНОЕ решение»)

  1. Любое чистый разработчик не может быть (и никогда не будет) надлежащим DevOp . Просто потому, что DevOp'ing требует другого, более широкого мышления, не ограничиваясь «я могу кодировать кодировать это» ... вы наступили на грабли и весело собираетесь бежать на их
  2. Сегодня в команде должно быть как минимум (кроме разработчиков):
    • хороший администратор используемого WWW-сервера ( хороший потому что он должен знать его под хорошим и использовал потому что разные серверы ... ну ... разные : для меня не проблема создавать динамические хосты в Apache, но я не смогу без предварительного RTFM в Boa, Tomcat, IIS, lighttpd, Nginx ...)
    • advanced Git-user (git-hooks будет не так очевиден в состоянии "готов к работе", обычный git-мальчики не разбираются в технических деталях, вопреки фанатичным проповедям)
    • хорошо NetworkAdmin (если вы выберете и используете две удаленные системы - ваш хост и GitHub, то единственная точка - это просто более простой и прозрачный способ - см. ниже)

GitHub, как 1) удаленная система 2) которой вы не владеете и которой не можете управлять на 100%, не является разумным разумным выбором: у вас всегда будут ограничения удаленное размещенное решение и дополнительный уровень сложности (удаленное общение GitHub - среда разработки) и дополнительная точка отказа. Сейчас есть много полезных Git-ориентированных решений (от простого обслуживания репозиториев до полного цикла ALM), которые можно развернуть на локальных системах

PS: Хорошо, вы исчерпали лимит моего бесплатного консультации, но могут нанять меня за платную плату (любого размера в любое время)

-2
ответ дан 5 December 2019 в 18:53

Теги

Похожие вопросы