Использование Perforce, совместное использование файла во многих проектах с разрешениями

Question

Я использую Perforce для управления несколькими веб-приложениями. Все приложения имеют общие интерфейсные файлы (css, JS и java speed code). Я хотел бы создать приложение для работы с ванилью и иметь файлы, совместно используемые с другими приложениями. Разработчики не смогут редактировать эти файлы в дочерних приложениях (что-то вроде импорта потоков p4), но когда они синхронизируются с приложением, он вытаскивает файлы приложений и (копии) разделяемых файлов. Редактирование этих файлов произойдет только в приложении для ванилин.

Я пытаюсь получить решение через потоки, чтобы работать. Проблема (как со стандартным отображением рабочей области) заключается в том, что я не могу сопоставить файл во многих местах.

Я построил свое приложение для работы с ванилью в качестве основного потока (сам по себе является конгломератом инструментов из разных мест в perforce). Затем я создал ветви развития для каждого приложения, используя комбинацию Share и Import. Рабочее пространство должно создаваться для соответствия каждому потоку.

Усложнение заключается в том, что каждое приложение имеет четыре среды (dev, qa, stage, live). Я не вижу четкого пути к этой проблеме.

Что не будет работать на нас: распределение

• HTTP. Сначала мы делили наши ресурсы js через веб-вызовы, но это создавало проблемы, когда сайт был отключен. Мы хотим, чтобы JS-файлы распространялись (через p4) как файлы LOCAL.
• Скомпилированные JARs. Эти общие файлы будут меняться слишком часто, и не будет скомпилированного кода. Это решение, но никто не хотел.

Мы новичок в потоках и привыкли к одному рабочему пространству для всего склада. Может быть, мне просто нужно это сделать?

Answer 1

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

У нас есть серия библиотек, которые поддерживаются внутренней группой, которые, как ожидается, будут использоваться в различных приложениях. Они держат в своих собственных потоках:

//LibraryA/main/... 
//LibraryB/main/... 

Для основных версий, они заперты вниз к распределениям:

//LibraryA/r1_0/... 
//LibraryB/r2_0/... 
//LibraryB/r2_0/... 

так, что мы можем поддерживать согласованность API без необходимости использовать @ спецификации в других потоках , Это может быть ненужным шагом для вас, но это помогает нам.

Тогда у нас есть проекты, а также в потоках:

//Project1/main/... 
//Project1/r1_0/... 
//Project2/main/... 
//Project2/r1_0/... 

Для каждого потока проекта, библиотеки включены, используя import директиву, поэтому спецификация потока для //Project1/main/... будет:

share ... 
import LibraryA/... //LibraryA/main/... 
import LibraryB/... //LibraryB/r1_0/... 

В этом случае строка share утверждает, что дочерние потоки main будут совместно использовать все файлы, принадлежащие непосредственно потоку, а строки import указывают на импорт только для чтения конкретной библиотеки возится в каталоги в потоке. В этом случае поток //LibraryA/main/... импортируется как LibraryA/... в дерево и т. Д.

В результате в извлеченную версии /Project1/main/:

project1.html 
images/p1i1.jpg 
images/p1i2.jpg 
LibraryA/l1c1.c 
LibraryA/l1c2.c 
LibraryB/l2c1.c 
LibraryB/l2c2.c 

При внесении изменений либо в /LibraryA/main/... потока или /LibraryB/r1_0 потока и /Project1/main/... является p4 sync ..., то вы получите последний код для каждой библиотеки.

Что касается качества/Дев/стадии/Prod среды, это не совсем ясно из вашего определения проблемы здесь, как эти разные, но вот два варианта:

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

Если предполагается, что они предполагают движение процесса из dev-> qa-> stage-> prod или аналогичного, вы можете реализовать их как потоки и явно продвигать код для перехода от одного к другому. Например:

//Project1/dev 
//Project1/qa 
//Project1/stage 
//Project1/prod 

В этом случае dev бы магистральный поток, qa может быть только для чтения поток с использованием виртуального типа потока , если они не имеют возможности редактирования на всех. stage, вероятно, будет релиз поток, который исходит из потока dev.

Большая часть этой структуры зависит от того, как вы определяете свой процесс разработки. В более гибком процессе магистрального отделение должно быть очень близко к разработчику ветви, и вы можете использовать непрерывной доставки от стабильного магистрального. В большей части процесса водопада у вас, вероятно, будет релиз филиалы, которые получают код от mainline филиал для тестирования и перехода к производству.