Простота администрирования… Как раз мне кажется в данном случае сложность администрирования. Как Вы справедливо заметили, число проектов не упрощает процесс.
Простота реализации… Собственно наш способ он тоже не такой сложный. А поддержка постоянно меняющихся конфигураций стоит в Вашем случае больше. Ну а готовые фичи Jenkinsa (или, например, Bamboo, который захотели попробовать наши коллеги из смежного подразделения) никто же не отменяет. Вполне возможно, что мы придем в итоге к нескольким готовым CI в цепочке, дабы не лишать никого возможности поэкспериментировать.
По порядку:
1. Именно такую задачу мы и решаем, напрмер команда build /trunk /deploy, в случае успешной сборки BuildServer передает управление на DeployServer.
2. Ограничить доступ к исходникам — очень актуальная задача для нас. Правда не совсем понимаю при чем тут разные конфигурации.
Запуск проекта с разными конфигурациями — это собственно все так же, на обработчике Jabber сообщений, есть конфигурация по умолчанию, при указании конкретной конфигурации она передается собственно платформе сборке, в нашем случае msbuild. Проблема связанная с безопасностью исходников существует в таком виде, что на сборщике хранится весь код, и нужно исключить возможность внедрения инъекции в допустим vcproj (хотя они делаются cmake-ом, но не в этом суть) в виде, например, prebuild-step-ов. Это решается двумя путями:
— ограничением прав локальной учетной записи, под которой выполняется сборка
— и собственно отсутствием какого-либо файлового доступа на BuildServer, внедренный код не сможет выложить исходники никуда далее этой машины (тем более по локалке), а на Storage выкладываются файлы только по опреденным правилам и проверкам
3.Если это A и С — это подпроекты в общем проекте и С является зависимостью A, то решение на уровне проекта, допустим так <?xml version="1.0" encoding="windows-1251"?>
...
Но скорее всего Вы про отдельные проекты, которые не всегда стоит запускать по порядку.
Тогда, не дорабатывая ничего, у нас это решится так:
build /C build /A, управление после сборки одного проекта передастся опять на BuildServer
А паралеллятся не проекты между собой, а один проект (я имею ввиду проект в широком смысле, содержащий некоторое количество vcproj-ей, csprojt-ей и т.д.)
Даже если vcproj один, то распараллеляться cl-подпроцессы, и только линкер будет идти в один поток — это решается технологией unitybuild, успешно внедренной.
Централизованное управление как раз то, чего хотелось избежать. Суть не в распределении нагрузки — она решается различными способами. Например, IncrediBuild-ом и ему подобными системами распараллеливания вычислений. Цель как раз децентрализация управления. Части народа из QA вообще в процессе работы не нужно общаться со сборочным сервером, и не хочется каждую задачу тестирования создавать на Hudson-е. А комбинацией параметров команды можно запустить множество различных конфигураций тестирования.
Если есть класс client, то переменную можно назвать cln clnt. С полным именем букв больше и писать уже нужно с разными префиксами/постфиксами, например, client_* а сокращать до гласных звучит некрасиво — clie
Да мы про конкурсы писали. Регистрация на форум была аж в два этапа 14 и 21 мая. Кто успел, тот и зарегистрировался, вот и весь критерий :) Желающих, конечно, много было, не все попали. Ну и второй путь был победить в конкурсах и выиграть инвайт.
А так можно либо дома онлайн трансляцию посмотреть либо придти в один из дружественных хакспейсов, где будет и трансляция и видеоконференция с основной площадкой форума.
Вообще, еще будет онлайн трансляция, на нее зарегистрироваться можно здесь
А так, уже после мероприятия будем смотреть, что, как и куда выложить, скрываться не будем :)
Вот тут в видео показано как отмычкой из банки из-под пепси замок открыть :)
Просто доказывать потом, что у нас правда «инструменты для мелких слесарных работ» это может быть та еще история. Да, были лазейки, но вещей, к которым можно придраться, оказалось больше чем тех, на чем можно вырулить. К сожалению, конкурс был бы классный…
Мы-то их продавать точно не собирались )) Но и купить не могли никак. А дразнить законодателей утверждениями, что у нас коллекция из нескольких сотен отмычек и мы ее просто так друзьям демонстрируем, обучаем и т.д. показалось не лучшей идеей…
Простота реализации… Собственно наш способ он тоже не такой сложный. А поддержка постоянно меняющихся конфигураций стоит в Вашем случае больше. Ну а готовые фичи Jenkinsa (или, например, Bamboo, который захотели попробовать наши коллеги из смежного подразделения) никто же не отменяет. Вполне возможно, что мы придем в итоге к нескольким готовым CI в цепочке, дабы не лишать никого возможности поэкспериментировать.
По порядку:
1. Именно такую задачу мы и решаем, напрмер команда build /trunk /deploy, в случае успешной сборки BuildServer передает управление на DeployServer.
2. Ограничить доступ к исходникам — очень актуальная задача для нас. Правда не совсем понимаю при чем тут разные конфигурации.
Запуск проекта с разными конфигурациями — это собственно все так же, на обработчике Jabber сообщений, есть конфигурация по умолчанию, при указании конкретной конфигурации она передается собственно платформе сборке, в нашем случае msbuild. Проблема связанная с безопасностью исходников существует в таком виде, что на сборщике хранится весь код, и нужно исключить возможность внедрения инъекции в допустим vcproj (хотя они делаются cmake-ом, но не в этом суть) в виде, например, prebuild-step-ов. Это решается двумя путями:
— ограничением прав локальной учетной записи, под которой выполняется сборка
— и собственно отсутствием какого-либо файлового доступа на BuildServer, внедренный код не сможет выложить исходники никуда далее этой машины (тем более по локалке), а на Storage выкладываются файлы только по опреденным правилам и проверкам
3.Если это A и С — это подпроекты в общем проекте и С является зависимостью A, то решение на уровне проекта, допустим так
<?xml version="1.0" encoding="windows-1251"?>
...
Но скорее всего Вы про отдельные проекты, которые не всегда стоит запускать по порядку.
Тогда, не дорабатывая ничего, у нас это решится так:
build /C build /A, управление после сборки одного проекта передастся опять на BuildServer
А паралеллятся не проекты между собой, а один проект (я имею ввиду проект в широком смысле, содержащий некоторое количество vcproj-ей, csprojt-ей и т.д.)
Даже если vcproj один, то распараллеляться cl-подпроцессы, и только линкер будет идти в один поток — это решается технологией unitybuild, успешно внедренной.
А так можно либо дома онлайн трансляцию посмотреть либо придти в один из дружественных хакспейсов, где будет и трансляция и видеоконференция с основной площадкой форума.
А так, уже после мероприятия будем смотреть, что, как и куда выложить, скрываться не будем :)
Просто доказывать потом, что у нас правда «инструменты для мелких слесарных работ» это может быть та еще история. Да, были лазейки, но вещей, к которым можно придраться, оказалось больше чем тех, на чем можно вырулить. К сожалению, конкурс был бы классный…