Клинбиз | Клининговая компания в Нижнем Новгороде | Цены на клининговые услуги и уборку

Особенности и порядок открытия филиала

Разбираемся как открыть филиал и когда это потребуется.

Услуга по открытию филиалов в настоящее время всё чаще становится актуальной и востребованной, так как не оценить преимущества, связанные с открытием филиалов просто невозможно.

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

Всё же, давайте попробуем разобраться с таким вопросом как открытие филиала и определить связанные с этим плюсы и минусы.

Важно при открытии филиала обратиться к специалисту, которые поможет и возьмет решение всех вопросов на себя. 

Чем отличается филиал от представительства

Часто филиал сравнивают с представительством, объясняя тем, что они являются обособленными подразделениями, а значит, разделения между ними быть не должно.

Наш «старый добрый друг» Гражданский кодекс РФ дает следующую формулировку филиала и представительства:

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

Филиалом является обособленное подразделение юридического лица, расположенное вне места его нахождения и осуществляющее все его функции или их часть, в том числе функции представительства.

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

Как говорится : «Всё познается в сравнении», поэтому каждое из этих двух обособленных подразделений обладает теми характеристиками, которые способны отвечать требованиям определенного юридического лица.

Представительства и филиалы не являются юридическими лицами, но их объединят одно общее понятие, как филиал так и представительство являются обособленными подразделениями.

Они наделяются имуществом создавшим их юридическим лицом и действуют на основании утвержденных им положений.

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

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

Давайте разберем эти моменты подробнее, а также определим общие черты, объединяющие филиал и представительство

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

Это всего лишь минимальный перечень, который можно поверхностно обозначить.

Как и любая юридическая процедура, создание филиала или представительства не может обойтись без решения общего собрания учредителей общества.

Данную обязанность закрепляет Гражданский кодекс РФ, указывающий также на то, что в устав организации в обязательном порядке должны быть внесены изменения, касающиеся как создания филиала/представительства, так и их прекращения деятельности в дальнейшем.

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

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

В статье 55 Гражданского кодекса РФ дается четкое указание, что представительства и филиалы должны быть указаны в учредительных документах создавшего их юридического лица.

Следует обратиться и к Налоговому кодексу РФ, в котором формулировка обособленного подразделения трактуется следующим образом: «…любое территориально обособленное от нее (организации) подразделение, по месту нахождения которого оборудованы стационарные рабочие места.

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

При этом рабочее место считается стационарным, если оно создается на срок более одного месяца…».

Конечно, из положений законодательства РФ можно сделать вывод о том, что создавая, например, структурное подразделение в обществе, в дальнейшем, его можно будет признать обособленным и легко спутать с филиалом/представительством, достаточно всего лишь оборудовать рабочие места, но, учитывая размытость данной информации, всё же необходимо учесть один важный фактор, влияющий на его полноценную работу, соответствовать целям создания и выполнять определенные функции обособленное подразделение сможет тогда, когда информация о нем будет содержаться в уставе юридического лица.

Основываясь практическим опытом, не зависимо от названия и общей формулировки обособленного подразделения, указанной Налоговым законодательством РФ, филиалы и представительства должны иметь документальное основание своего создания, только тогда деятельность филиала или представительства можно считать законной.

Под документальным основанием понимается, как раз, формулировка в Уставе головной организации о создании либо филиала либо представительства, а также наличие Положения о деятельности обособленного подразделения.

Учредительные документы должны дополнительно содержать информацию об адресе (место нахождение) филиалов или представительств и, если это необходимо, контактные телефоны.

Ни одно обособленное подразделение не может полноценно функционировать без руководителя и Положения, регламентирующего его деятельность.

Руководитель обособленного подразделения назначается юридическим лицом, создавшим филиал или представительство и осуществляет свои функции на основании доверенности, выданной исключительно руководителю обособленного подразделения.

Положения о филиале или представительстве определяются юридическим лицом – головной организацией.

Как правило, в Положении указываются основные цели и задачи создания обособленного подразделения, виды деятельности, органы управления, информация по имуществе филиала/представительства, способы и порядок взаимодействия обособленного подразделения и общества, а также компетенция органов управления.

Когда стоит открывать филиал?

Тема открытия филиальной сети по определенным регионам является распространенной и заманчивой, но для того, чтобы открыть для начала хотя бы один филиал, необходимо всё-таки ответить на единственный вопрос: «Зачем?».

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

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

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

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

Безусловно, у каждого варианта имеются свои достоинства и недостатки.

С филиалами легче работать, так как крупные клиенты отдают преимущество именно филиалам или представительствам, а те, в свою очередь, начинают зарабатывать репутацию – одно из главных составляющих успеха.

Среди минусов – риски, которые как «русская рулетка» в случае небольшого отступления от плана могут обернуться крахом всего бизнеса в целом.

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

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

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

Итак, пришло время пройтись по документам, необходимым для открытия филиала

• принятие решения общим собранием участников об открытии филиала;
• внесение изменений в Устав юридического лица в связи с созданием филиала;
• утверждение Положения о филиале;
• подача заявления в регистрационный орган по месту нахождения юридического лица;
• изготовление печати филиала.

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

По истечении этого времени регистрационный орган выдает Свидетельство, новую редакцию Устава, Положение о филиале, выписку из ЕГРЮЛ.

Далее необходимо поставить на учет обособленное подразделение в налоговом органе.

В соответствии со статьей 23 Налогового Кодекса РФ налогоплательщики, в течение одного месяца со дня создания подразделения или прекращения деятельности организации через него (закрытия), обязаны письменно сообщать в налоговый орган обо всех обособленных подразделениях, созданных на территории Российской Федерации.

Постановка на учет в налоговых органах по месту нахождения обособленного подразделения осуществляется на основании заявления.

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

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

Основными документами филиала являются

• Положение о филиале;
• Свидетельство об изменениях юридического лица – головной организации;
• Выписка из Единого государственного реестра юридических лиц;
• Уведомление о постановке на учет в налоговом органе;
• Решение о создании филиала;
• Постановка филиала во внебюджетных фондах;
• Приказ о назначении на должность руководителя филиала.

Если Вам требуется помощь юриста по регистрации  — смело обращайтесь — консультация совершенно бесплатно! 

Советуем почитать:

Выход компании в регионы. Инструкция к применению

Светлана Моисеева

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

Подробнее о системе оперативно-аналитического контроля продаж, включая: содержание, рабочие формы, отчеты, процедуры – здесь>>

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

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

Исследование рынка

Для сбора и получения маркетинговой информации, конечно, лучше всего обратиться к профессионалам. Если же нет возможности привлечь сторонних специалистов, то можно попытаться провести исследование своими силами. Для этого компании необходимо провести исследование в 3 направлениях:

             Анализ рынка региона,

             Анализ основных клиентов (потребителей),

             Анализ конкурентов.

Как выбрать оптимальные регионы для экспансии?

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

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

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

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

Подробнее о создании региональной дистрибуторской сети – здесь

Как же определиться с регионом?

В первую очередь, мы выбираем города — милионники: Москва, Санкт-Петербург, Новосибирск, Екатеринбург, Нижний Новгород, Самара, Омск, Казань, Челябинск, Ростов-на-Дону, Уфа, Волгоград, Пермь.

Далее находим крупные города, максимально приближенные к выбранному городу — миллионику. Например, городами — спутниками Самары являются Новокуйбышевск, Чапаевск, Жигулёвск. Следовательно, если открыть в Самаре филиал, то в городах – спутниках целесообразно иметь торговых представителей.

Далее необходимо определить финансовую привлекательность выбранных регионов. Информацию можно получить из статистических данных Росстата (www.kgs.ru). Нас интересуют, в первую очередь, следующие параметры региона: численность населения, рейтинг инвестиционной привлекательности, оборот розничной торговли, оборот оптовой торговли, среднемесячная зарплата, среднемесячный доход семей, динамика цен, промышленная структура региона, состояние логистики в регионе.

После того как рынки определены следует создать профиль потребителей (клиентов) на этих рынках и соотнести его с профилем основных клиентов компании. Для этого необходимо провести анализ основных потребителей.

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

В данной части исследования необходимо определить существуют ли в регионе так называемые «якорные» клиенты для компании (существующие, потенциальные).

Анализ основных потребителей должен дать информацию о компаниях, занимающих определенные доли рынка, ассортименте потребляемых товаров, среднем объеме и сумме заказа.

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

Анализ конкурентов (производителей и дистрибуторов) должен дать представление об основных участниках рынка, существующих торговых марках на рынке; ценовой политике конкурентов, об условиях поставок и оплат, о методах продвижения (реклама, способы увеличения продаж), каналах сбыта продукции, дать оценку слабых и сильных сторон конкурентов.

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

После получения маркетинговой информации можно переходить к следующему шагу – выбору модели:

o        Развитие дилерской сети

o        Работа по франшизе

o        Открытие регионального представительства/филиала

o        Региональный (территориальный) представитель: либо самостоятельное присутствие, либо выделенная команда (в месте расположения дилера).

o        Специализированные компании («рынок под ключ»)[1].

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

Таблица 1 Модели регионального развития

Для определения наиболее оптимальной модели следует посчитать разницу в марже, планируемую к получению из региона. К выбору модели работы следует отнестись очень серьезно, так как при неправильном выборе, затраты на работу филиала могут «съесть» всю прибыль, и в итоге филиал не выйдет на самоокупаемость.

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

Многие компании, вышедшие на рынок Екатеринбурга, столкнулись с проблемой рентабельности филиала. Не все из них серьезно отнеслись к тому факту, что рынок уже сформирован и поделен между крупными дистрибуторами (особенно это касается продуктового направления). Это повлекло за собой большие финансовые затраты на поддержание филиала, так как развитие территории шло очень медленно. Поэтому для компаний, которые не готовы к большим финансовым затратам, оптимально подойдут модели: регионального представителя или работа с крупным дистрибутором, который может стать эксклюзивным представителем компании и заняться продвижением ее продукции. В дальнейшем уже можно думать и над открытием своего филиала.

Открывать свои филиалы (представительства) следует только в том случае, если в самой компании выстроена система продаж с четкой регламентацией и жестким управлением.

Те компании, которые решаются открыть филиал или представительство зачастую стоят перед вопросом какую организационно-правовую форму работы выбрать (таблица 2).

Таблица 2. Основные характеристики филиалов и представительств

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

В своей статье мы рассматриваем варианты выхода в регионы в большей степени для торгово-производственных компаний. Если говорить о выходе в регионы торговой сети, то существуют две основные стратегии выхода: открытие собственных торговых точек или покупка (слияние) региональной сети. Для выбора той или иной стратегии необходимо рассчитать чистый приведенный доход для обоих вариантов, по которому можно судить о целесообразности использования той или иной стратегии выхода в регион.

Определив рынки и модели работы, компании приступают к проработке юридических аспектов.

Юридическое оформление деятельности

Юридический аспект деятельности компании является одной из главных составляющих при работе в регионе. В нашей практике мы столкнулись со случаем, когда неправильно оформленные документы «заморозили» деятельность филиала на 2 месяца, что вызвало сложности с поставками в FMCG-сети региона, так как договора уже были заключены с филиалом.

Важным моментом при открытии филиала является выбор финансовой модели работы: без открытия отдельного расчетного счета или с открытием отдельного расчетного счета Филиалы как структурные подразделения организации могут выделяться либо не выделяться на отдельный баланс.

Трудно сказать какая финансовая модель лучше (таблица 3).

Таблица 3.Финансовые модели работы

Может быть использован еще один\ вариант — создание отдельного юридического лица. Такой путь снижает  риски головной компании от возникновения проблем с « заказными» региональными проверками или неправомерными действиями филиала. Необходимо учесть, что при такой правовой форме создания филиала в Уставе организации необходимо прописать ограничение полномочий Директора филиала, а не Генерального директора филиала, так как если в Уставе будет указан Генеральный директор, то по действующему законодательству ограничить его полномочия будет невозможно.

В процессе работы над проектами для дистрибуторских компаний мы постоянно сталкивались с проблемой отсутствия качественного финансового и управленческого учета.

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

Отсутствие строгого учета движения товарно — денежных потоков – это прямой путь к злоупотреблениям, поэтому организация финансового учета в филиале и постановка отчетности, должны быть организованы еще до открытия филиала. Это поможет формализовать учет, избежать человеческих и временных затрат в будущем.

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

Подбор персонала

Формирование команды филиала является одним из сложнейших вопросов при подготовке его открытия.

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

Для поиска такого сотрудника, как правило, HR-служба компании обращается в региональные рекрутинговые компании. Основываясь на своем опыте, рекомендуем обращаться в несколько агентств.

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

Еще одним вариантом подбора управленца может стать приглашение вашим HR-отделом топ-менеджера из небольших региональных компаний. Как правило, такие люди хорошо знают рынок и обладают клиентской базой.

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

Ошибки при запуске филиала

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

Как показывает практика, в первые два года работы филиала наблюдается высокая текучесть персонала, что отрицательно влияет на его самоокупаемость. Чаще всего это связано с элементарным отсутствием контроля в области мотивации персонала филиала. Очень часто система премирования в филиале отдается на откуп руководителю, и распределение премий становится сильно зависимым от «любви» или «не любви» руководителя к конкретному подчиненному, что вызывает сильное раздражение в коллективе и является сильным демотиватором персонала.

Подробнее о разработке системе мотивации в рамках коммерческой политики компании  – здесь>>

Еще одним демотиватором работы филиала является тот факт, что центральный офис «спускает» план освоения территории (план регионального развития) на квартал (полгода) в филиал без согласования цифр с филиалом, то есть сотрудники удаленного подразделения фактически исключены из процесса планирования. Это приводит к размыванию ответственности, так как филиал не хочет отвечать за те цифры, которые ему были спущены свыше. Такое планирование не учитывает реальное состояние клиентской базы и возможностей филиала.

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

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

Как правило, многие филиалы отпускаются в «свободное плавание» после постановки целей и задач из центрального офиса. А ведь именно из-за отсутствия надлежащего контроля, качественного обмена информацией, методической помощи со стороны компании назревают различные противоречия, влекущие за собой серьезные сбои в работе филиала. Начинается «противостояние» и «кивание» центрального офиса на филиал, а филиала на офис.

В процессе анализа функциональных подразделений компаний в своих проектах мы сталкивались с проблемой двойного (тройного) подчинения филиала. Так, например, в одной дистрибуторской компании руководителю филиала (чаще его подчиненным) давали распоряжения руководители нескольких структурных подразделений центрального офиса (генеральный директор, директор по продажам, директор по развитию, директор по маркетингу). Это дестабилизировало работу филиала, вызывало нервотрепку в работе и отнимало время сотрудников удаленного подразделения на выполнения заданий из центрального офиса. Информация и запросы в филиал должны проходить через «одно окно» — непосредственного руководителя филиала. В филиале должен быть только один руководитель и только через него должны проходить запросы для его подчиненных.

Что же необходимо сделать, чтобы наладить качественную работу с филиалами? Вот, некоторые наши рекомендации:

1. Выделить в центральном офисе ответственного за филиал, в любое время находящегося на связи с филиалом и оперативно решающего возникающие вопросы и проблемы.
2. Максимально задействовать технические ресурсы: телефоны, электронную почту, сайт,Skype,внутрикорпоративный ICQ и т.д.
3. Прописать корпоративные стандарты, в которых будут прописаны процедуры взаимодействия филиала с офисом, подчиненность, сроки и виды предоставляемой информации, формы отчетов и т.д.
4. При открытии филиала необходимо продумать простую мотивационную схему, которая должна быть прозрачной и понятной сотрудникам филиала. Рекомендуется минимизировать зависимость мотивационных схем персонала филиала от субъективной оценки руководителя.
5. Проводить семинары по командообразованию, стажировки в центральном офисе, слеты директоров филиалов для обмена опытом.

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

Рис.1.Технология выхода в регион

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

Такая схема работы используется оптовыми и производственными компаниями.

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

Надеемся, что этот материал будет полезен для вас. Больше информации о проблемах работы с филиалами вы можете найти на страницах сайта www.unitcon.ru

[1] В данной статье эта модель рассматривать не будет, так как она высоко затратна.

Управление сбытом № 7, 2012 г

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

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

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

Зарегистрироваться на обучение и получить ответы на интересующие вопросы Вы можете у менеджера проекта по тел: (495) 987-10-57 или по электронной почте: Этот адрес электронной почты защищён от спам-ботов. У вас должен быть включен JavaScript для просмотра.

Организация филиала: подводные камни и плюсы.

В данной статье Санкт-Петербургская консалтинговая компания Advising Bureau РЕШЕНИЯ УСПЕХА рассматривает основные плюсы, минусы и ошибки в организации процесса экспансии в регионы по пути создания Филиальной сети. Модель экспансии в регионы на основе модели создания собственной филиальной сети является одной из самых стабильных моделей. Одновременно она является самой дорогой, сложной моделью развития бизнеса, а также самой рентабельной и 100% управляемой. Так, например, при организации дилерской сети в течение первых двух лет сотрудничества в 80% случаев возникают противоречия в оперативном взаимодействии, что является невозможным при использовании Филиальной модели развития компании.

Основные минусы данной модели экспансии:

1. Требует достаточно больших инвестиций (по сравнению с другими моделями экспансии).

2. Все риски неудачного открытия филиала лежат на головной компании.

3. Требует постоянного контроля за движением денежных средств и товаро — материальных ценностей.

Основные плюсы данной модели экспансии:

1. 100%-ая управляемость филиала.

2. Абсолютное соблюдение корпоративных политики и правил.

3. Возможность вносить изменения в поставленные задачи и требования в режиме реального времени.

4. Упрощается «обратная связь» с руководством филиала и, соответственно, возможность своевременной корректировки позиции компании в регионе.

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

6. Появляется взаимозаменяемость – в случае отсутствия по какой–либо причине специалиста в головном офисе его может временно заменить специалист из филиала.

7. Готовится смена кадров – профессиональные сотрудники филиала могут быть приглашены на работу в головной офис компании.

8. 100%-ая гарантия того, что филиал, в отличие от других моделей экспансии, не передумает быть Вашим партнёром в регионе.

9. Инвестиции, вложенные в собственное подразделение, увеличивают стоимость Вашей компании в целом.

10. Происходит «экспансия торговой марки» компании, она становится более узнаваемой и, соответственно, возрастает её цена.

Однако, в большинстве компаний при организации филиалов, использование «плюсов» данной модели экспансии в регионы почему-то уходит на второй план или вовсе не контролируется и не используется. Так, 61% компаний не проводят анализ будущих cash — flow после начала работы филиалов и сталкиваются с проблемой размывания оборотных средств между собственными подразделениями.

В 67% компаний филиалы имеют организационные сложности и проблемы в управляемости, в результате чего, более 80% филиалов в первые год-два после начала работы, имеют высокую текучесть персонала, что приводит к увеличению затрат на открытие и содержание филиала. На основании практического анализа Advising Bureau РЕШЕНИЯ УСПЕХА находит причину данных проблем не в профессиональном уровне конкретных сотрудников филиалов, а в отсутствии чёткой политики Головной компании в управлении филиалами и стандартизации необходимых бизнес – процессов, функций и полномочий сотрудников.

Среди часто повторяющихся ошибок в организации Филиалов можно выделить:

1. Сознательное занижение требований к профессиональному уровню сотрудников при первичном наборе персонала в филиал (встречается в 76% случаев).

2. Первичная постановка упрощённых задач и целей перед руководством филиала.

3. Требование выполнения всеми сотрудниками филиала не стандартизированных правил и обязанностей.

4. Полное отсутствие проработанных Корпоративных Стандартов.

5. Отсутствие проработанной административно – функциональной модели управления.

6. Отсутствие возможностей для контроля движения денежных средств в филиале.

7. Отсутствие возможностей для контроля сохранности товаро — материальных ценностей.

8. Отсутствие контроля за лояльностью и карьерным ростом сотрудников филиала.

9. Отсутствие единой корпоративной системы учета и контроля (программного продукта).

10. Ошибки в подготовке юридических документов.

Организация филиалов, помимо трудностей и «подводных камней» при старте, может принести компании и ощутимую пользу в будущем, т.к. филиал может служить поставщиком профессиональных кадров для головной компании и полигоном для «обкатки» новых управленческих решений и/или организационных изменений.

При опросе топ-менеджеров 50 компаний, имеющих в своей структуре филиалы и представительства, на предмет возможностей карьерного роста для сотрудников филиала и взаимозаменяемости сотрудников головного офиса и филиала, выяснилось что:

1. Только 34% руководителей рассматривают кандидатуры сотрудников филиалов на имеющиеся вакансии в головном офисе.

2. 47 % руководителей считают эффективность перевода сотрудников из филиала в головной офис отрицательной.

3. 19% руководителей готовы рассмотреть перевод сотрудника из филиала в головной офис только при инициативе самого сотрудника.

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

Хотя, привлечение сотрудников из филиалов в головной офис даёт следующие плюсы:

1. Экономия временных и материальных затрат на обучение специалиста.

2. Каждый сотрудник филиала начинает понимать, что его карьерный рост не ограничивается «стенами» филиала.

3. Желание сотрудников оказаться нужными в головном офисе заставляет их более качественно относиться к своим должностным обязанностям.

4. Возможность перевода сотрудника из филиала в головной офис заставляет последнего постоянно заниматься собственным дополнительным образованием.

5. Увеличивается лояльность сотрудников компании.

Источник: http://www.klerk.ru/boss/?81274

Что делать, если вам не удаётся контролировать работу филиалов в других городах

Строительная компания открыла филиал в Санкт-Петербурге, чтобы обслуживать интересы постоянных клиентов головного офиса. Дополнительная задача — привлечение новых клиентов. Структура филиала была достаточно простая — наняли руководителя филиала, который самостоятельно формировал штат, расходовал деньги, которые поступали из головного офиса, и направлял отчёты бухгалтеру. Через несколько месяцев после открытия всё вышло из-под контроля. Направляемые отчёты были неконкретными. Часть клиентов жаловалась на невыполнение работ, часть не оплачивала выполненные.

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

Вопрос с расходованием денежных средств был более сложным, однако помог контроль закупок и всех выплат строительным бригадам. Моё личное знакомство со всеми работниками позволило решить вопросы, связанные с имевшимися у них трудностями взаимодействия с руководителем филиала. Проблема заключалась в том, что строительные бригады были полностью зависимы от него. Он определял их объём работы и размер оплаты труда. Мы выявили случаи, когда работники подписывали ведомости о получении больших сумм денег, чем они получали на самом деле. Это приводило и к потере компанией денег, и к падению лояльности работников. Руководителя филиала уволили. Деятельность нового руководителя я полностью перепроверял на месте.

11 шагов к созданию своего колл центра, услуги контакт центра для бизнеса, управление колл-центром, MANGO OFFICE

Директор филиала, главный инженер, начальник производственного участка, главный механик, высшее образование, зарплата от 50000, Красноярск. Опыт работы 21 год

Опыт работы

Июль 2015 — настоящее время

Начальник участка ГПМ — ЗАО «ПОЛЮС ЛОГИСТИКА»

Организация работы участка, организация и планирование ремонтов и ТО ГПМ

Май 2014 — Июнь 2015

Инженер, преподаватель спец/дисциплин — КГБПОУ «Енисейский многопрофильный тхникум»

Организация работы гаража, организация работы автотранспорта, планирование ремонтов и ТО, преподавание.

Июль 2013 — Апрель 2014

Начальник производственного участка «Верхнепашинский» — ЗАО «Енисйэнергоком»

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

Декабрь 2012 — Май 2013

Директор филиала «Магадан» — ЗАО «ПОЛЮС ЛОГИСТИКА»

Организация работы производственных участков, работа с заказчиками и подрядными организациями, создание производственных участков и подразделений с «нуля» и т.п.

Май 2012 — Декабрь 2012

Заместитель технического директора по транспорту — ЗАО «ПОЛЮС ЛОГИСТИКА»

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

Сентябрь 2011 — Январь 2012

Заместитель технического директора по производству — ЗАО «ПОЛЮС ЛОГИСТИКА»

Организация работы производственных участков, производственных баз (Назимово,Лесосибирск), организация и контроль работы складского хозяйства, планирование, поступление и выдача ТМЦ, работа с заказчиками, контроль документооборота и т.д.

Декабрь 2005 — Сентябрь 2011

Прошел уть от водителя до главного инженера автотранспортного цеха. — ЗАО «ПОЛЮС»

В подчинении было 1200 человек

Февраль 1999 — Июль 2005

Начальник автомобильной колонны, в подчинении 120 человек — ОАО «Краснокаменское рудоуправление»

Статья 5. Филиалы и представительства общества / КонсультантПлюс

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

Создание обществом филиалов и открытие представительств на территории Российской Федерации осуществляются с соблюдением требований настоящего Федерального закона и иных федеральных законов, а за пределами территории Российской Федерации также в соответствии с законодательством иностранного государства, на территории которого создаются филиалы или открываются представительства, если иное не предусмотрено международными договорами Российской Федерации.

2. Филиалом общества является его обособленное подразделение, расположенное вне места нахождения общества и осуществляющее все его функции или их часть, в том числе функции представительства.

3. Представительством общества является его обособленное подразделение, расположенное вне места нахождения общества, представляющее интересы общества и осуществляющее их защиту.

4. Филиал и представительство общества не являются юридическими лицами и действуют на основании утвержденных обществом положений. Филиал и представительство наделяются имуществом создавшим их обществом.

Руководители филиалов и представительств общества назначаются обществом и действуют на основании его доверенности.

Филиалы и представительства общества осуществляют свою деятельность от имени создавшего их общества. Ответственность за деятельность филиала и представительства общества несет создавшее их общество.

5. Филиалы и представительства общества должны быть указаны в едином государственном реестре юридических лиц.

(см. текст в предыдущей редакции)

Открыть полный текст документа

Управление филиалами — GitHub Docs

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

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

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

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

Вы всегда можете создать ветку в GitHub Desktop, если у вас есть доступ для чтения к репозиторию, но вы можете отправить ветку в GitHub, только если у вас есть права записи в репозиторий.

Администраторы репозитория могут включить защиту в филиале. Если вы работаете с защищенной веткой, вы не сможете удалить или принудительно отправить в ветку. Администраторы репозитория могут включить другие параметры защищенной ветви, чтобы обеспечить выполнение определенных рабочих процессов перед объединением ветви. Для получения дополнительной информации см. «О защищенных ветках».

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

1. Щелкните История .
2. Щелкните правой кнопкой мыши фиксацию, из которой вы хотите создать новую ветку, и выберите Create Branch from Commit .
3. В поле Имя введите имя новой ветви.
4. Щелкните Создать ответвление .

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

1. В верхней части приложения щелкните Текущая ветвь , затем щелкните ветку, которую вы хотите опубликовать.
2. Щелкните Опубликовать ветку .

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

Совет : Вы можете установить поведение по умолчанию для переключения ветвей в настройках Advanced . Для получения дополнительной информации см. «Настройка основных параметров».

1. На рабочем столе GitHub щелкните Current Branch .
2. В списке веток щелкните ветку, на которую хотите переключиться.
3. Если вы сохранили незафиксированные изменения, выберите Оставить мои изменения или Перенести мои изменения , затем щелкните Переключить ветвь .

Вы не можете удалить ветку, если она в настоящее время связана с открытым запросом на вытягивание. Вы не можете отменить удаление ветки.

1. В верхней части приложения щелкните Current Branch , затем щелкните ветвь, которую вы хотите удалить.
2. В строке меню щелкните Branch , затем щелкните Удалить … . Вы также можете нажать shift ⌘ command D .

1. В верхней части приложения щелкните Текущая ветвь , затем щелкните ветвь, которую вы хотите удалить.
2. В строке меню щелкните Branch , затем щелкните Удалить … . Также можно нажать Ctrl Shift D .

Почему мои взносы не отображаются в моем профиле?

Проблемы, запросы на вытягивание и обсуждения

Проблемы, запросы на вытягивание и обсуждения появятся на вашем графике вкладов, если они были открыты в автономном репозитории, а не в вилке.

Совершает

Коммитов появятся на графике ваших вкладов, если они соответствуют всем из следующих условий:

• Адрес электронной почты, используемый для коммитов, связан с вашей учетной записью GitHub.
• Коммиты были сделаны в автономном репозитории, а не в вилке.
• Сделано коммитов:
  • В ветке репозитория по умолчанию
  • В ветке gh-pages (для репозиториев с сайтами проектов)

Дополнительные сведения о сайтах проектов см. В разделе «О страницах GitHub».

Кроме того, должен выполняться хотя бы один из следующего:

• Вы являетесь соавтором репозитория или членом организации, владеющей репозиторием.
• Вы разделили репозиторий.
• Вы открыли пул-реквест или проблему в репозитории.
• Вы отметили репозиторий.

Примечания:

• При перемещении коммитов первоначальные авторы коммита и лицо, которое перебазировало коммиты, в командной строке или на GitHub, получают кредит за вклад.

Коммит выполнен менее 24 часов назад

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

Ваш локальный адрес электронной почты фиксации Git не связан с вашей учетной записью

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

Вы можете проверить адрес электронной почты, используемый для фиксации, добавив .патч до конца URL-адреса фиксации, например https://github.com/octocat/octocat.github.io/commit/67c0afc1da354d8571f51b6f0af8f2794117fd10.patch:

  Из источника 67c0afc1da354d8571f51b6f0af8f2794117fd10 Пн, 17 сен, 00:00:00 2001
От: Octocat 
Дата: 27 апреля 2014 г., 15:36:39 +0530
Тема: [PATCH] обновленный индекс для лучшего приветственного сообщения
  

Адрес электронной почты в поле От: — это адрес, который был установлен в локальных настройках конфигурации git.В этом примере для фиксации используется адрес электронной почты [email protected] .

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

Общие адреса электронной почты, такие как [email protected] , нельзя добавить в учетные записи GitHub. Если вы используете такой адрес электронной почты для своих коммитов, они не будут связаны с вашим профилем GitHub и не будут отображаться на диаграмме ваших вкладов.

Фиксация не была сделана по умолчанию или

Коммиты засчитываются, только если они сделаны в ветке по умолчанию или в ветке gh-pages (для репозиториев с сайтами проектов). Для получения дополнительной информации см. «О страницах GitHub».

Если ваши коммиты находятся в ветке не по умолчанию или не в gh-pages и вы хотите, чтобы они учитывались в ваших вкладах, вам нужно будет выполнить одно из следующих действий:

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

Коммит выполнен в вилке

Коммиты, сделанные в вилке, не засчитываются в ваш вклад. Чтобы они засчитывались, вы должны выполнить одно из следующих действий:

• Откройте запрос на перенос, чтобы ваши изменения были объединены в родительский репозиторий.
• Чтобы отсоединить вилку и превратить ее в автономный репозиторий на GitHub, обратитесь в службу поддержки GitHub или в службу поддержки GitHub Premium.Если у вилки есть собственные вилки, сообщите службе поддержки GitHub, должны ли вилки перемещаться вместе с вашим репозиторием в новую сеть или оставаться в текущей сети. Для получения дополнительной информации см. «О вилках».

Создание организационной схемы и управление ею - Справка и поддержка Docebo

Введение

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

Создание филиала в организационной структуре

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

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

Чтобы добавить новую ветку (папку), нажмите кнопку плюс в правом верхнем углу страницы, затем нажмите элемент New Branch . На выдвижной панели дайте ветви имя и код. Обратите внимание, что если для папки задан определенный язык, который не является языком по умолчанию на платформе, имя папки по-прежнему отображается на языке платформы по умолчанию. Помните, что код, который вы назначаете, будет одинаковым для каждого языка. Код представляет собой буквенно-цифровое значение, отличное от нуля, и не является обязательным полем. Обратите внимание, что если вы не назначите код филиалу, он не будет виден и доступен для выбора в форме регистрации платформы. Теперь в разделе панели Destination решите, где разместить папку. Если вы хотите, чтобы эта новая ветвь была папкой в ​​корневой ветке, выберите корневую ветвь (папку в верхней части списка). В качестве альтернативы, если вы хотите, чтобы новая ветвь была вложенной папкой (вложенной веткой), выберите папку из списка, в которую вы хотите поместить эту новую вложенную ветвь.По завершении нажмите Подтвердите .

Управление папкой или ветвью

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

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

Добавление пользователей в филиал

Чтобы добавить пользователей в ветку, выберите пользователей из списка на странице Все пользователи , затем нажмите значок с многоточием в правом нижнем углу страницы.В меню нажмите на пункт Добавить в ветку . На выдвижной панели выберите ветку, в которую вы хотите поместить выбранных пользователей, затем нажмите Подтвердить .

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

Перемещение пользователей в филиал

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

Удаление пользователей из филиала

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

Лучшие Лрактики

• Поскольку пользователя можно перемещать из ветки в другую, только вручную и через API или CSV, учтите, что очень вложенную структуру ветвей может быть трудно поддерживать в актуальном состоянии, особенно если ваши пользователи очень часто переходят из ветки в другую. . Подготовьте свою ветвящуюся структуру с учетом того, как вы хотите доставлять учебный контент (по BU, по ролям, по региону ...), а не копировать иерархическую структуру компании.Если в организационной структуре вашей компании происходят постоянные изменения, постарайтесь сохранить филиалы на более высоком уровне и работать с автоматическими группами с помощью дополнительных полей, которые могут быть обновлены вами как суперадмином или самими пользователями.
• Старайтесь по возможности избегать использования корневой ветви (уровень 0), поскольку она ведет себя иначе, чем все другие ветви (например, вы не сможете отображать пользователей, которые ТОЛЬКО в корневой ветви: система всегда будет в этом случае отображать пользователей из всего дерева организационной диаграммы).Пользователи всегда должны размещаться в структуре ветвей под корнем, это поможет фильтровать при выборе пользователей для отчетности и регистрации.

Разработка и развертывание с ветвями • Руководства по Beanstalk

Введение

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

Кодирование в ветвях - это простая практика, которая помогает вам и вашей работе быть более организованными. Филиалы позволяют легко поддерживать «незавершенную» работу отдельно от завершенного, протестированного и стабильного кода. Это не только эффективный способ сотрудничества с другими, но также позволяет автоматизировать развертывание обновлений и исправлений на ваших серверах.

Кодирование в главном / магистральном «ответвлениях»

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

• в Subversion это папка с названием trunk ,
• в Git это ветка под названием master .

Без какой-либо настройки ваша первая фиксация в любом репозитории будет сделана в эту рабочую ветвь.

Каждая система контроля версий использует свой подход к созданию, объединению и удалению веток.Мы сосредоточимся на общем процессе разработки и предлагаем вам обратиться к документации на предпочитаемый вами VCS для получения конкретных сведений о командах:

Ветвление рабочего процесса

Использование веток может показаться сложным без каких-либо указаний. Мы собираемся помочь вам, сосредоточив внимание на двух конкретных вариантах использования веток и преимуществах их включения в рабочий процесс.

Преимущества филиалов: особенности построения и исправление ошибок

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

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

Если вся ваша работа выполняется в рабочей ветке по умолчанию вашего репозитория, вам нужно выяснить, как сохранить работу, которую вы сделали до сих пор на Feature Y , вернуть ваш репозиторий в состояние, в котором оно было в, когда вы развернули Feature X , внесите исправление, а затем повторно представьте свою работу из Feature Y .Это беспорядочно, и вы потенциально можете потерять часть своей работы или внести новые ошибки.

Вместо этого вы должны выполнять всю свою работу в ветвях feature или для исправления ошибок и позволить VCS делать тяжелую работу за вас. Вы должны разветвлять свой репозиторий с того места, где был развернут Feature X , создавая альтернативную рабочую копию, над которой вы можете выполнять новую работу. Ваша ветка Feature Y включает всю историю и код репозитория, но отдельная история «начинается» с момента создания ветки.Это позволяет вам работать с ветвью Feature Y , отдавая предпочтение вашему сердцу, не нарушая код, который вы развернули для выпуска Feature X .

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

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

Лучшие практики с ветвями функций и ошибок

• Старайтесь не передавать незавершенную работу в рабочую ветвь вашего репозитория по умолчанию.
• Создавайте ветку каждый раз, когда вы начинаете нетривиальную работу, включая функции и сложные исправления ошибок.
• Не забудьте удалить ветки функций после того, как они были объединены в стабильную ветку. Это сохранит ваш репозиторий в чистоте.

Преимущества ветвления: ветки серверной среды

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

Мы говорили о вашей «рабочей ветке по умолчанию», но вы также можете думать об этом как о ветке среды разработки. Рекомендуется содержать эту ветку в чистоте - это легко сделать, используя ветки функций и исправлений ошибок и объединяя их обратно в ветку разработки только после того, как они будут протестированы. Другими словами, в любой момент времени ваша ветка разработки должна содержать только стабильный код.Поэтому с этого момента в этом руководстве мы будем использовать имя «стабильный» для обозначения этой ветки.

Использование производственных и промежуточных филиалов

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

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

Различия ветвей для упрощенного просмотра кода и примечания к выпуску

Когда ваша среда разработки была обновлена ​​с помощью протестированных функций и исправлений ошибок, вы можете использовать свой VCS , чтобы провести различие между стабильной ветвью и промежуточной ветвью, чтобы увидеть, что будет развернуто, чего в настоящее время нет.Это прекрасная возможность найти некачественный или неполный код, отладочный код и другие остатки разработки, которые не следует развертывать. Эта разница также может быть полезна при написании заметок о выпуске.

Никогда не выполняйте слияние с ветвями среды без развертывания

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

С ветвями среды вы никогда не захотите фиксировать изменения непосредственно в ветке. Объединяя код только из стабильной ветки в промежуточную или производственную ветвь, вы гарантируете, что изменения будут происходить в одном направлении: от ветвей функций и исправлений ошибок к стабильной и промежуточной средам и от стабильной к производственной. Это сохраняет вашу историю в чистоте и, опять же, позволяет вам быть уверенным в том, какой код работает в каких средах.

  триггер:
- владелец
- релизы / *
  

  # сборка конкретной ветки
спусковой крючок:
  ветви:
    включают:
    - владелец
    - релизы / *
    исключать:
    - релизы / старые *
  

  триггер:
  ветви:
    включают:
      - refs / tags / {tagname}
    исключать:
      - refs / tags / {othertagname}
  

  триггер:
  ветви:
    включают:
    - '*' # должен заключаться в кавычки, поскольку "*" является зарезервированным символом YAML; мы хотим строку
  

  # сборка конкретной ветки с пакетной обработкой
спусковой крючок:
  партия: правда
  ветви:
    включают:
    - владелец
  

  # сборка по конкретному пути
спусковой крючок:
  ветви:
    включают:
    - владелец
    - релизы / *
  пути:
    включают:
    - документы
    исключать:
    - документы / README.мкр
  

  # специфический тег
спусковой крючок:
  теги:
    включают:
    - v2. *
    исключать:
    - v2.0
  

  # Трубопровод без триггера CI
триггер: нет
  

  триггер:
  ветви:
    включают:
    - владелец
    - релизы / *
    - особенность/*
    исключать:
    - релизы / старые *
    - особенность / * - работает
  пути:
    включают:
    - '*' # то же, что '/' для корня репозитория
    исключать:
    - 'docs / *' # то же, что 'docs /'
  

  пр:
- владелец
- релизы / *
  

  пр:
  ветви:
    включают:
    - '*' # должен заключаться в кавычки, поскольку "*" является зарезервированным символом YAML; мы хотим строку
  

  # конкретная ветка
пр:
  ветви:
    включают:
    - владелец
    - релизы / *
    исключать:
    - релизы / старые *
  

  # конкретный путь
пр:
  ветви:
    включают:
    - владелец
    - релизы / *
  пути:
    включают:
    - документы
    исключать:
    - документы / README.мкр
  

  # auto cancel false
пр:
  autoCancel: false
  ветви:
    включают:
    - владелец
  

  пр:
  autoCancel: boolean # указывает, должны ли дополнительные нажатия на PR отменять выполняющиеся прогоны для того же PR. По умолчанию true
  ветви:
    include: [string] # имена веток, которые вызовут сборку
    exclude: [string] # имена веток, которые не будут
  пути:
    include: [строка] # пути к файлам, которые должны совпадать для запуска сборки
    exclude: [string] # пути к файлам, по которым не запускается сборка
  drafts: boolean # строить ли черновики PR, по умолчанию true
  

  # нет триггеров PR
пр: нет
  

  шагов:
- checkout: self # self представляет репо, в котором был найден исходный файл YAML конвейеров.
  clean: boolean # очищать ли каждый раз
  fetchDepth: number # глубина коммитов для запроса Git на выборку
  lfs: boolean # загружать ли файлы Git-LFS
  подмодули: true | рекурсивный # установлен в 'true' для одного уровня подмодулей или 'рекурсивный' для получения подмодулей подмодулей
  path: string # путь для проверки исходного кода относительно каталога сборки агента (e.г. \ _work \ 1)
  persistCredentials: boolean # установлен в 'true', чтобы оставить токен OAuth в конфигурации Git после начальной выборки
  

  шагов:
- checkout: self # self представляет репо, в котором был найден исходный файл YAML конвейеров.
  clean: boolean # очищать ли каждый раз
  fetchDepth: number # глубина коммитов для запроса Git на выборку
  lfs: boolean # загружать ли файлы Git-LFS
  подмодули: true | рекурсивный # установлен в 'true' для одного уровня подмодулей или 'рекурсивный' для получения подмодулей подмодулей
  path: string # путь для проверки исходного кода относительно каталога сборки агента (e.г. \ _work \ 1)
  persistCredentials: boolean # установлен в 'true', чтобы оставить токен OAuth в конфигурации Git после начальной выборки
  

  git -c http.https: //  .extraheader = "AUTHORIZATION: Basic " обновление подмодуля --init --recursive
  

  шагов:
- checkout: self # self представляет репо, в котором был найден исходный файл YAML конвейеров.
  clean: boolean # очищать ли каждый раз
  fetchDepth: number # глубина коммитов для запроса Git на выборку
  lfs: boolean # загружать ли файлы Git-LFS
  подмодули: true | рекурсивный # установлен в 'true' для одного уровня подмодулей или 'рекурсивный' для получения подмодулей подмодулей
  path: string # путь для проверки исходного кода относительно каталога сборки агента (e.г. \ _work \ 1)
  persistCredentials: boolean # установлен в 'true', чтобы оставить токен OAuth в конфигурации Git после начальной выборки
  

  шагов:
- оформление заказа: нет # Не синхронизировать источники
  

  шагов:
- checkout: self # self представляет репо, в котором был найден исходный файл YAML конвейеров.
  clean: boolean # очищать ли каждый раз
  fetchDepth: number # глубина коммитов для запроса Git на выборку
  lfs: boolean # загружать ли файлы Git-LFS
  подмодули: true | рекурсивный # установлен в 'true' для одного уровня подмодулей или 'рекурсивный' для получения подмодулей подмодулей
  path: string # путь для проверки исходного кода относительно каталога сборки агента (e.г. \ _work \ 1)
  persistCredentials: boolean # установлен в 'true', чтобы оставить токен OAuth в конфигурации Git после начальной выборки
  

  git clean -ffdx
git reset --hard HEAD
  

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

  вакансий:
- job: string # название работы, A-Z, a-z, 0-9 и подчеркивание
  ...
  Рабочее пространство:
    чистый: выходы | ресурсы | all # что убрать перед запуском задания
  

Это дает следующие чистые параметры.

• выводит : та же операция, что и параметр очистки, описанный в предыдущей задаче проверки, плюс: удаляет и воссоздает $ (Build.BinariesDirectory) . Обратите внимание, что $ (Build.ArtifactStagingDirectory), и $ (Common.TestResultsDirectory) всегда удаляются и воссоздаются перед каждой сборкой независимо от любого из этих параметров.

• ресурсов : удаляет и воссоздает $ (Build.SourcesDirectory) . Это приводит к инициализации нового локального репозитория Git для каждой сборки.

• все : удаляет и воссоздает $ (Agent.BuildDirectory) . Это приводит к инициализации нового локального репозитория Git для каждой сборки.

Выберите параметр Очистить в свойствах задачи Получить источники в конвейере и выберите один из следующих параметров.

• Источники : конвейер сборки выполняет отмену любых изменений в $ (Build.SourcesDirectory) . Более конкретно, следующие команды Git выполняются до выборки источника.

    git clean -ffdx
  git reset --hard HEAD
    

• Источники и каталог вывода : та же операция, что и вариант Источники выше, плюс: удаляет и воссоздает $ (Build.BinariesDirectory) .Обратите внимание, что $ (Build.ArtifactStagingDirectory) и $ (Common.TestResultsDirectory) всегда удаляются и воссоздаются перед каждой сборкой независимо от любого из этих параметров.

• Каталог исходных файлов : удаляет и воссоздает $ (Build.SourcesDirectory) . Это приводит к инициализации нового локального репозитория Git для каждой сборки.

• Все каталоги сборки : удаляет и воссоздает $ (Agent.BuildDirectory) . Это приводит к инициализации нового локального репозитория Git для каждой сборки.

Источники этикеток

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

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

В классическом редакторе выберите YAML , выберите задачу Получить источники , а затем настройте там нужные свойства.

Вы можете настроить параметр Источники тегов в свойствах задачи Получить источники в вашем конвейере.

В формате тега вы можете использовать определяемые пользователем и предварительно определенные переменные, которые имеют область действия «Все."Например:

  $ (Build.DefinitionName) _ $ (Build.DefinitionVersion) _ $ (Build.BuildId) _ $ (Build.BuildNumber) _ $ (Моя.Переменная)
  

Первые четыре переменные предопределены. Моя.Переменная может быть определена вами на вкладке переменных.

Конвейер сборки помечает ваши источники тегом Git.

Некоторые переменные сборки могут давать значение, не являющееся допустимой меткой. Например, такие переменные, как $ (Build.RequestedFor) и $ (Build.DefinitionName) может содержать пробелы. Если значение содержит пробелы, тег не создается.

После того, как источники помечаются конвейером сборки, в завершенную сборку автоматически добавляется артефакт с Git ref refs / tags / {tag} . Это дает вашей команде дополнительную отслеживаемость и более удобный способ перехода от сборки к созданному коду. Тег считается артефактом сборки, поскольку он создается сборкой. Когда сборка удаляется вручную или с помощью политики хранения, тег также удаляется.

Предопределенные переменные

Когда вы создаете репозиторий GitHub, большинство предопределенных переменных становятся доступными для ваших заданий. Однако, поскольку Azure Pipelines не распознает личность пользователя, выполняющего обновление в GitHub, для следующих переменных устанавливается идентификатор системы, а не идентификатор пользователя:

• Сборка.Запрошено для
• Build.RequestedForId
• Сборка.RequestedForEmail

Обновления статуса

Существует два типа статусов, которые Azure Pipelines отправляет обратно на GitHub: базовые статусы и GitHub Check Runs.Функциональность GitHub Checks доступна только в приложениях GitHub.

Статусы конвейера отображаются в разных местах пользовательского интерфейса GitHub.

• Для PR они отображаются на вкладке PR-бесед.
• Для отдельных коммитов они отображаются при наведении курсора на отметку состояния после времени фиксации на вкладке коммитов репо.

Подключения PAT или OAuth GitHub

Для конвейеров, использующих подключения PAT или OAuth GitHub, статусы отправляются обратно в фиксацию / PR, которая инициировала запуск.API статуса GitHub используется для публикации таких обновлений. Эти статусы содержат ограниченную информацию: статус конвейера (сбой, успех), URL-адрес для обратной ссылки на конвейер сборки и краткое описание статуса.

Статусы для подключений PAT или OAuth GitHub отправляются только на уровне выполнения. Другими словами, вы можете обновить один статус для всего цикла. Если у вас есть несколько заданий в прогоне, вы не можете публиковать отдельный статус для каждого задания. Однако несколько конвейеров могут публиковать разные статусы в одной и той же фиксации.

Проверки GitHub

Для конвейеров, настроенных с помощью приложения Azure Pipelines GitHub), статус отправляется обратно в форме проверок GitHub. GitHub Checks позволяет отправлять подробную информацию о состоянии конвейера, а также о тестах, покрытии кода и ошибках. GitHub Checks API можно найти здесь.

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

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

Если щелкнуть ссылку «Повторный запуск» рядом с именем «Проверить запуск», Azure Pipelines попытается повторить запуск, который сгенерировал этот запуск. Результирующий запуск будет иметь тот же номер запуска и будет использовать ту же версию исходного кода, конфигурации и файла YAML, что и исходная сборка. Только те задания, которые не удалось выполнить при первоначальном запуске, и все зависимые нижестоящие задания будут запущены снова.Нажатие на ссылку «Повторно запустить все неудачные проверки» даст тот же эффект. Это то же поведение, что и при нажатии кнопки «Повторить попытку» в пользовательском интерфейсе Azure Pipelines. Нажатие на «Повторно запустить все проверки» приведет к новому запуску с новым номером запуска и внесет изменения в конфигурацию или файл YAML.

FAQ

Проблемы, связанные с интеграцией GitHub, делятся на следующие категории:

• Типы подключения: Я не уверен, какой тип подключения использую для подключения моего конвейера к GitHub.
• Неудачные триггеры: Мой конвейер не запускается, когда я отправляю обновление в репо.
• Ошибка проверки: Мой конвейер запускается, но на этапе проверки произошел сбой.
• Неправильная версия: Мой конвейер работает, но использует неожиданную версию исходного кода / YAML.
• Отсутствуют обновления статуса: Мои PR на GitHub заблокированы, поскольку Azure Pipelines не сообщает об обновлении статуса.

Типы подключения

Как узнать тип подключения GitHub, который я использую для своего конвейера, для устранения неполадок триггеров?

Устранение проблем с триггерами во многом зависит от типа соединения GitHub, которое вы используете в своем конвейере.Есть два способа определить тип подключения - из GitHub и из Azure Pipelines.

• Из GitHub: если репо настроено для использования приложения GitHub, то статусы PR и коммитов будут Check Runs. Если в репозитории Azure Pipelines настроены подключения OAuth или PAT, статусы будут в «старом» стиле. Быстрый способ определить, являются ли статусы проверочными прогонами или простыми статусами, - взглянуть на вкладку «беседа» в PR GitHub.

  • Если ссылка «Подробности» перенаправляет на вкладку «Проверки», это означает выполнение проверки и репо использует приложение.
  • Если ссылка «Подробности» перенаправляет на конвейер Azure DevOps, тогда статус является статусом «старого стиля», и репозиторий не использует приложение.

• Из Azure Pipelines: вы также можете определить тип подключения, проверив конвейер в пользовательском интерфейсе Azure Pipelines. Откройте редактор конвейера. Выберите Триггеры , чтобы открыть классический редактор конвейера. Затем выберите вкладку YAML , а затем шаг Получить источники . Вы увидите баннер Авторизовано с использованием соединения: , указывающий на соединение службы, которое использовалось для интеграции конвейера с GitHub.Название сервисного подключения представляет собой гиперссылку. Выберите его, чтобы перейти к свойствам подключения службы. В свойствах служебного подключения будет указан тип используемого подключения:

  • Приложение Azure Pipelines указывает на подключение приложения GitHub
  • oauth указывает на соединение OAuth
  • personalaccesstoken указывает на аутентификацию PAT

Как переключить конвейер на использование приложения GitHub вместо OAuth?

Использование приложения GitHub вместо соединения OAuth или PAT - это рекомендуемая интеграция между GitHub и Azure Pipelines.Чтобы переключиться на приложение GitHub, выполните следующие действия:

1. Перейдите сюда и установите приложение в организации GitHub вашего репозитория.
2. Во время установки вы будете перенаправлены в Azure DevOps, чтобы выбрать организацию и проект Azure DevOps. Выберите организацию и проект, содержащие классический конвейер сборки, для которого вы хотите использовать приложение. Этот выбор связывает установку приложения GitHub с вашей организацией Azure DevOps. Если вы выбрали неправильный вариант, вы можете посетить эту страницу, чтобы удалить приложение GitHub из своей организации GitHub и начать заново.
3. На следующей открывшейся странице вам не нужно продолжать создание нового конвейера.
4. Измените конвейер, посетив страницу конвейеров (например, https://dev.azure.com/YOUR_ORG_NAME/YOUR_PROJECT_NAME/_build), выбрав свой конвейер и нажав «Изменить».
5. Если это конвейер YAML, выберите меню Триггеры , чтобы открыть классический редактор.
6. Выберите в конвейере шаг «Получить источники».
7. На зеленой полосе с текстом «Авторизовано с использованием подключения» нажмите «Изменить» и выберите подключение приложения GitHub с тем же именем, что и организация GitHub, в которую вы установили приложение.
8. На панели инструментов выберите «Сохранить и поставить в очередь», а затем «Сохранить и поставить в очередь». Щелкните ссылку на запуск конвейера, который был поставлен в очередь, чтобы убедиться, что он успешно завершен.
9. Создайте (или закройте и снова откройте) запрос на вытягивание в репозитории GitHub, чтобы убедиться, что сборка успешно поставлена ​​в очередь в разделе «Проверки».

Почему я не могу выбрать репозиторий GitHub в Azure Pipelines?

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

Когда я выбираю репозиторий во время создания конвейера, я получаю сообщение об ошибке «Репозиторий {repo-name} используется с приложением Azure Pipelines GitHub в другой организации Azure DevOps».

Это означает, что ваш репозиторий уже связан с конвейером в другой организации. События CI и PR из этого репозитория не будут работать, поскольку они будут доставлены в другую организацию. Вот шаги, которые вы должны предпринять, чтобы удалить сопоставление с другой организацией, прежде чем приступить к созданию конвейера.

1. Откройте запрос на перенос в репозитории GitHub и сделайте комментарий / azp, где . Это сообщает об организации Azure DevOps, с которой сопоставлен репозиторий.

2. Чтобы изменить сопоставление, удалите приложение из организации GitHub и переустановите его. При повторной установке убедитесь, что выбрали правильную организацию при перенаправлении в Azure DevOps.

Неисправные триггеры

Я только что создал новый конвейер YAML с триггерами CI / PR, но конвейер не запускается.

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

• Переопределяются ли триггеры YAML CI или PR настройками конвейера в пользовательском интерфейсе? При редактировании конвейера выберите ... , а затем Триггеры .

  Проверьте Переопределить триггер YAML отсюда. Настройка для типов триггера ( Непрерывная интеграция или Проверка запроса на извлечение ), доступных для вашего репо.

• Используете ли вы соединение с приложением GitHub для подключения конвейера к GitHub? См. Типы подключения, чтобы определить тип вашего подключения. Если вы используете подключение к приложению GitHub, выполните следующие действия:

  • Правильно ли настроено сопоставление между GitHub и Azure DevOps? Откройте запрос на перенос в репозитории GitHub и сделайте комментарий / azp, где . Это сообщает об организации Azure DevOps, с которой сопоставлен репозиторий.

    • Если ни одна организация не настроена для создания этого репозитория с помощью приложения, перейдите на страницу https://github.com///settings/installations и завершите настройку приложения.

    • Если сообщается о другой организации Azure DevOps, значит, кто-то уже установил конвейер для этого репозитория в другой организации. В настоящее время у нас есть ограничение: мы можем сопоставить репозиторий GitHub только с одной организацией DevOps.Только конвейеры в первой организации Azure DevOps могут запускаться автоматически. Чтобы изменить сопоставление, удалите приложение из организации GitHub и переустановите его. При повторной установке убедитесь, что выбрали правильную организацию при перенаправлении в Azure DevOps.

• Используете ли вы OAuth или PAT для подключения конвейера к GitHub? См. Типы подключения, чтобы определить тип вашего подключения. Если вы используете соединение GitHub, выполните следующие действия:

  1. Подключения OAuth и PAT полагаются на веб-перехватчики для передачи обновлений в Azure Pipelines.В GitHub перейдите к настройкам вашего репозитория, а затем к Webhooks. Убедитесь, что веб-перехватчики существуют. Обычно вы должны видеть три веб-перехватчика - push, pull_request и issue_comment. Если вы этого не сделаете, вы должны повторно создать подключение к службе и обновить конвейер, чтобы использовать новое подключение к службе.

  2. Выберите каждый из веб-перехватчиков в GitHub и убедитесь, что полезная нагрузка, соответствующая фиксации пользователя, существует и была успешно отправлена ​​в Azure DevOps. Здесь вы можете увидеть ошибку, если о событии не удалось передать в Azure DevOps.

• GitHub может регулировать трафик из Azure DevOps. Когда Azure Pipelines получает уведомление от GitHub, он пытается связаться с GitHub и получить дополнительные сведения о репозитории и файле YAML. Если у вас есть репо с большим количеством обновлений и запросов на вытягивание, этот вызов может завершиться ошибкой из-за такого регулирования. В этом случае посмотрите, можно ли снизить частоту сборок с помощью пакетной обработки или более строгих фильтров путей / ветвей.

• Ваш конвейер приостановлен или отключен? Откройте редактор конвейера, а затем выберите Настройки для проверки.Если ваш конвейер приостановлен или отключен, триггеры не работают.

• Вы обновили файл YAML в правильной ветке? Если вы отправляете обновление в ветку, то файл YAML в той же ветке управляет поведением CI. Если вы отправляете обновление в исходную ветвь, то YAML-файл, полученный в результате слияния исходной ветки с целевой ветвью, управляет поведением PR. Убедитесь, что файл YAML в правильной ветке имеет необходимую конфигурацию CI или PR.

• Правильно ли настроили триггер? Когда вы определяете триггер YAML, вы можете указать предложения include и exclude для ветвей, тегов и путей.Убедитесь, что предложение include соответствует деталям вашего коммита и что предложение exclude не исключает их. Проверьте синтаксис триггеров и убедитесь, что он точен.

• Использовали ли вы переменные при определении триггера или путей? Это не поддерживается.

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

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

• Есть ли в фильтрах пути подстановочные знаки? Узнайте об ограничениях использования подстановочных знаков в ваших путях, как описано в этой статье.

• Вы только что запихнули новую ветку? Если это так, новая ветка может не начать новый запуск. См. Раздел «Поведение триггеров при создании новых веток».

Мои триггеры CI или PR работают нормально.Но теперь они перестали работать.

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

• Есть ли у вас конфликты слияния в вашем PR? Для PR, который не запускал конвейер, откройте его и проверьте, есть ли у него конфликт слияния. Разрешите конфликт слияния.

• Возникли задержки в обработке событий push или PR? Обычно вы можете проверить это, посмотрев, является ли проблема специфической для одного конвейера или является общей для всех конвейеров или репозиториев в вашем проекте.Если push-обновление или PR-обновление любого из репозиториев демонстрирует этот симптом, у нас могут быть задержки в обработке событий обновления. Проверьте, не происходит ли сбой в обслуживании на нашей странице статуса. Если на странице состояния отображается проблема, значит, наша команда уже начала работать над ней. Часто проверяйте страницу на наличие обновлений по проблеме.

Я не хочу, чтобы пользователи переопределяли список ветвей для триггеров при обновлении файла YAML. Как я могу это сделать?

Пользователи с разрешениями на внесение кода могут обновлять файл YAML и включать / исключать дополнительные ветки.В результате пользователи могут включать свою собственную функцию или пользовательскую ветвь в свой YAML-файл и отправлять это обновление в функцию или пользовательскую ветвь. Это может привести к запуску конвейера для всех обновлений этой ветви. Если вы хотите предотвратить такое поведение, вы можете:

1. Измените конвейер в пользовательском интерфейсе Azure Pipelines.
2. Перейдите в меню Триггеры .
3. Выберите Отсюда переопределите триггер непрерывной интеграции YAML .
4. Укажите ветви, которые нужно включить или исключить для триггера.

При выполнении этих шагов любые триггеры CI, указанные в файле YAML, игнорируются.

Неудача при оформлении заказа

Я вижу следующую ошибку в файле журнала на этапе проверки. Как мне это исправить?

  удаленный: репозиторий не найден.
фатальный: репозиторий  не найден
  

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

Неправильная версия

В конвейере используется неправильная версия файла YAML.Это почему?

• Для триггеров CI файл YAML, который находится в ветке, которую вы нажимаете, оценивается, чтобы определить, следует ли запускать сборку CI.
• Для триггеров PR файл YAML, полученный в результате слияния исходной и целевой ветвей PR, оценивается, чтобы определить, следует ли запускать сборку PR.

Отсутствуют обновления статуса

Мой PR в GitHub заблокирован, поскольку Azure Pipelines не обновлял статус.

Это может быть временная ошибка, из-за которой Azure DevOps не может взаимодействовать с GitHub.Повторите проверку в GitHub, если вы используете приложение GitHub. Или сделайте тривиальное обновление PR, чтобы увидеть, можно ли решить проблему.

Статьи по теме

Контроль версий - фабрика данных Azure

• 04.06.2021
• Читать 15 минут

В этой статье

ОТНОСИТСЯ К: Фабрика данных Azure Azure Synapse Analytics

По умолчанию пользовательский интерфейс (UX) фабрики данных Azure создается непосредственно для службы фабрики данных.Этот опыт имеет следующие ограничения:

• Служба фабрики данных не включает репозиторий для хранения объектов JSON для ваших изменений. Единственный способ сохранить изменения - нажать кнопку « Опубликовать все» , и все изменения публикуются непосредственно в службе фабрики данных.
• Служба фабрики данных не оптимизирована для совместной работы и контроля версий.
• Шаблон Azure Resource Manager, необходимый для развертывания самой фабрики данных, не включен.

Чтобы обеспечить лучший опыт разработки, фабрика данных Azure позволяет настроить репозиторий Git с помощью репозитория Azure или GitHub. Git - это система контроля версий, которая упрощает отслеживание изменений и совместную работу. В этой статье будет описано, как настраивать и работать в репозитории git, а также выделены лучшие практики и руководство по устранению неполадок.

Примечание

Для Azure Government Cloud доступен только GitHub Enterprise Server .

Чтобы узнать больше о том, как фабрика данных Azure интегрируется с Git, просмотрите 15-минутное обучающее видео ниже:

Преимущества интеграции с Git

Ниже приведен список некоторых преимуществ, которые интеграция git дает при разработке:

• Управление исходным кодом: Поскольку рабочие нагрузки вашей фабрики данных становятся критически важными, вы можете интегрировать свою фабрику с Git, чтобы использовать несколько преимуществ системы управления версиями, например:
  • Возможность отслеживать / проверять изменения.
  • Возможность отменить изменения, внесшие ошибки.
• Частичное сохранение: При разработке с использованием службы фабрики данных нельзя сохранить изменения в виде черновика, и все публикации должны пройти проверку фабрики данных. Независимо от того, не завершены ли ваши конвейеры или вы просто не хотите терять изменения в случае сбоя компьютера, интеграция с git позволяет вносить инкрементные изменения ресурсов фабрики данных независимо от того, в каком состоянии они находятся. Настройка репозитория git позволяет сохранять изменения, позволяя вы публикуете только после того, как проверили свои изменения к своему удовлетворению.
• Сотрудничество и контроль: Если у вас есть несколько членов команды, работающих на одной фабрике, вы можете позволить своим товарищам по команде сотрудничать друг с другом с помощью процесса проверки кода. Вы также можете настроить свою фабрику так, чтобы не все участники имели одинаковые права. Некоторым членам команды может быть разрешено вносить изменения только через Git, и только определенные люди в команде могут публиковать изменения в фабрике.
• Улучшенный CI / CD: Если вы развертываете в нескольких средах с непрерывным процессом доставки, интеграция с git упрощает определенные действия.Некоторые из этих действий включают:
  • Настройте конвейер выпуска так, чтобы он запускался автоматически при любых изменениях, внесенных в фабрику разработчиков.
  • Настройте свойства на заводе, которые доступны в качестве параметров в шаблоне диспетчера ресурсов. Может быть полезно сохранить в качестве параметров только необходимый набор свойств, а все остальное жестко запрограммировать.
• Лучшая производительность: Средняя фабрика с интеграцией git загружается в 10 раз быстрее, чем одна авторинговая служба фабрики данных.Это улучшение производительности связано с тем, что ресурсы загружаются через Git.

Примечание

Создание непосредственно с помощью службы фабрики данных отключено в пользовательском интерфейсе фабрики данных Azure при настройке репозитория Git. Изменения, внесенные с помощью PowerShell или SDK, публикуются непосредственно в службе фабрики данных и не вводятся в Git.

Подключиться к репозиторию Git

Существует четыре различных способа подключения репозитория Git к вашей фабрике данных как для Azure Repos, так и для GitHub.После подключения к репозиторию Git вы можете просматривать и управлять своей конфигурацией в концентраторе управления в разделе Конфигурация Git в разделе Source control

Метод настройки 1: Домашняя страница

На домашней странице фабрики данных Azure выберите Настроить репозиторий кода вверху.

Метод конфигурации 2: холст для разработки

На холсте разработки UX фабрики данных Azure выберите раскрывающееся меню Фабрики данных , а затем выберите Настроить репозиторий кода .

Метод настройки 3: Центр управления

Перейдите к концентратору управления в ADF UX. Выберите Git configuration в разделе Source control . Если у вас нет подключенного репозитория, нажмите Настроить .

Метод конфигурации 4: Во время создания фабрики

При создании новой фабрики данных на портале Azure вы можете настроить информацию о репозитории Git на вкладке Конфигурация Git .

Примечание

При настройке git на портале Azure такие параметры, как имя проекта и имя репо, необходимо вводить вручную, а не в раскрывающемся списке.

Автор с интеграцией Azure Repos Git

Визуальная разработка с интеграцией Azure Repos с Git поддерживает управление версиями и совместную работу над конвейерами фабрики данных. Вы можете связать фабрику данных с репозиторием организации Azure Repos Git для управления версиями, совместной работы, управления версиями и т. Д.Одна организация Azure Repos Git может иметь несколько репозиториев, но репозиторий Azure Repos Git может быть связан только с одной фабрикой данных. Если у вас нет организации или репозитория Azure Repos, следуйте этим инструкциям, чтобы создать свои ресурсы.

Примечание

Вы можете хранить файлы сценариев и данных в репозитории Azure Repos Git. Однако вам необходимо вручную загрузить файлы в хранилище Azure. Конвейер фабрики данных не передает автоматически скрипт или файлы данных, хранящиеся в репозитории Azure Repos Git, в хранилище Azure.

Настройки Azure Repos

На панели конфигурации отображаются следующие параметры репозитория кода Azure Repos:

Примечание

Если вы используете Microsoft Edge и не видите никаких значений в раскрывающемся списке учетной записи Azure DevOps, добавьте https: //*.visualstudio.com в список надежных сайтов.

Используйте другой клиент Azure Active Directory

Репозиторий Azure Repos Git может находиться в другом клиенте Azure Active Directory. Чтобы указать другой клиент Azure AD, у вас должны быть разрешения администратора для подписки Azure, которую вы используете.Для получения дополнительной информации см. Изменение администратора подписки

  {
    "publishBranch": "factory / adf_publish"
}