Люблю покушать, а особенно пожрать.
Т.к. glutton (англ. обжора), как правило, везде занят, а так же потому что покушать люблю очень, то стал gluttton, ну и для солидности, а потом мне это стало казаться ещё и более глазоприятным вариантом, начал писать с заглавной буквы: итого на выходе имеем — Gluttton.
P.S. Сижу на 11.2 KDE. Планировал перейти на 11.4 LXDE, но т.к. в KDE столько всего нового, а в LXDE «небольшие улучшения», то теперь вот и засомневался куда податься…
Также, судя по имеющимся данным, в стране пока что работает мобильная связь, но отключены SMS.
У нас сейчас там две группы в командировке и мы и посредник целый день не можем им на мобильные (местного оператора) дозвониться — девушка-робот на местном языке что то пытается объяснить.
Oracle так просто не сдался. Разработчики признали, что право на название «Hudson» принадлежит Oracle и, чтобы не было проблем в будущем, решили переименовать проект. Предложенное название — Jenkins
Пх. Тоже мне проблема. Да пусть переименовывают во что угодно.
P.S.Может заодно и мужика с фона уберут, а то он мне как то приелся.
При программировании на С++ и тем более С# под Windows (чем я занимаюсь) покидать «любимую IDE» просто некуда.
Возможно я перемудрил с ответами. Просто я хотел обратить внимание на следующие продукты: Subversion, Mercurial, NAnt, NUnit, TeamCity, Cruise Control на Hudson само-собой (может быть вы уже с ними и знакомы). «Покидание IDE» в данном контексте заключается не в переходе на Notepad, а в запуске процесса сборки не из IDE, а из NAnt (bat, ...) или Hudson (TeamCity, ...). Совершенно очевидно, что для того, что бы скрипт запустить, его нужно создать и вот как раз в процессе создания этих скриптов и приходит понимание, что и как нужно делать.
Не думайте что я там фанатик и с флагом Майкрософта хожу на барикады, нет.
Что за глупости? Я совершенно не против ни MS ни тем более VS (особенно Express версии), хотя сам в последнее время перешел на Linux и работаю с Mono…
Не являюсь специалистом по вопросам CI, поэтому возможны заблуждения с моей стороны, но тем не менее.
Не очень понял почему в системе непрерывной интеграции самое главное — это система контроля версий.
Не то что бы главное, скорее базовое — то с чего начинается построение. Я например могу себе представить CI без генерации документации, или без разворачивания приложения, на худой конец, даже без тестирования, но вто без checkout'а — с большим трудом.
Сначала, вы создаете проект, к нему тесты, создаете репозиторий, для хранения кода, затем скрипт, который выполняет сборку проекта и запускает тесты, а в заключении «цепляете» это скрипт на сервер интеграции.
В конце концов checkout кода — единственное, что этой самой системе непрерывной интеграции нужно от системы контроля версий.
Пожалуй да.
И не пофигу ли ей делать этот checkot коммандой «svn checkout», «copy» или кликом в GUI?
Непрерывная интеграция — процесс автоматический и в процессе сборки «кликов» быть не должно. «Клик» должен быть один — «Сделать пи… ато» «Build».
Я просто предположил, что поскольку Visual Studio решает массу задач (а помимо изменения исходных кодов у неё правда еще масса функций) то могут быть и удобные под неё плагины для системы непрерывной интеграции.
По сути вопроса, мне ответить нечего — я не знаю о наличии (равно как и об отстутствии) подобных plugin'ов. Просто не могу не поделиться опытом и не отметить тот факт, что использования plugin'ов без понимания сути больше зло чем добро. Это субьективно и основано исключительно на личном опыте (точнее сказать на личных ошибках). Если вы понимаете чего вы хотите от непрерывной интеграции, то plugin помочь может, а в противном случае, по моему мнению, наврятли. Хотя…
Уверен, что если возможность интегрирования в IDE реализована, то это полезно и востребовано. Но в то же время хотел бы предостеречь tangro от использования подобных решений. Возможно это излишнее занудство, но сначало нужно понять процесс изнутри, а уже затем использовать инструменты инкапсулирующие его и предоставляющие более удобный интерфейс.
Приведу несколько примеров.
Например некотрые IDE поддерживают интеграцию с VCS и глупо бы было бы не использовать хотя бы время от времени эту возможность. Но познавать VCS по этому плагину — это тернистый путь ведущий в никуда.
Ещё одним примером может стать замечательный инструмен для работами с БД Access. С его помощью можно достаточно быстро создавать простые БД и, что более важно, проектировать отчеты и формы. Опять же таки, было бы глупо, в подходящих случаях не использовать Access. Но изучать основы БД по Access, на мой взгляд, зло. Почитайте вопросы которые задают на форумах новички по Access и, напрмер, по MS SQL Server или MySQL…
Т.о., резюмируя, хочу категорически порекомендовать tangro покинуть уютное окружение любимой IDE и познакомиться с сторонними инструментами и только после получения некоторого опыта инкапсулировать те операции, содержание которых понятно посредством plugin'ов.
chaliy, спасибо за ссылку — расширю кругозор (тем более, что: «TeamCity now supports continuous integration builds on Windows and Unix-based platforms under Mono framework.»).
Visual Studio — это всего лишь IDE и в процессе непрерывной ингерации роли по большому счету не принимает. Совершенно не важно с помощью какого инструмента вы будете изменять исходные коды. При организации непрерывной интеграции отправной точкой, как уже сказал maxim_ge должна стать система управлениями версиями. А дальше по вкусу…
Между собой связаны репозиторий (Subversion) багтрекер (Trac) и сервер интеграции (Hudson).
Но видать или из-за кривых рук или же от не знания профит от этого нулевой.
Связка репозиторий — багтрекер:
— возможность в Trac просматривать содержимое репозитория;
— возможность в Trac просматривать diff'ы.
Связка репозиторий — сервер интеграции:
— возможность в Hudson просматривать события произошедшие в репозитории в рамках build'ов.
Связка багтрекер — сервер интеграции:
— возможность быстрого перехода из сервера ингерации к тикету (если commit'ах в коментарий помещать номер тикета (например: «Fix defect #42.»), то Hudson преобразует их в ссылки и позволяет переходить по ним к тикету в Trac).
Это все те возможности, которыми я сумел овладеть. Буду признателен если, кто-нибудь поделиться опытом и поскажет, какую ещё выгоду можно извлечь от связки указанных инструментов.
Поэтому, в случае если вам необходимо реализовать свой сценарий сборки, для которого не достаточно набора стандартных плагинов из группы «Сборка», можно пойти тремя путями:
Я использую NAnt.
Поэтому «непрерывностью» в моём случае пришлось поступиться и начать запускать тесты не по hook'ам SVN, а по расписанию.
Не думаю, что есть смысл запускать сборку после каждого коммита (особенно на начальной стадии проекта). Поэтому потеря не велика. Я тоже сначала ставил hook на коммит, но потом отказался от этой идеи и начал запускать сборку «в ручную» по факту закрытия тикета в багтрэкере (а у меня это не всегда один коммит).
Просто я считаю, что автор, в первую очередь, должен уважать читателя.
Мне кажется, что автор старался, т.к. диаграммы выполнены в линиях разной толщины, надписи сделаны печатными буквами и нет следов подтираний и помарок.
Да и вообще, чего это я за автора «отдуваюсь», пусть он сам и скажет, в конце-концов!
> Не у нас. У меня слово контроль вообще отсутствует в лексиконе. Контроль является затратной частью для компании.
С очень похожим доводом у нас на предприятии (не связано с разработкой ПО) на последнем совещании вообще запретили использовать слово «контроль» — теперь только «сопровождение»! О как!
Хотя лично мне не понятно, как это может положительно повлиять на процесс изготовления продукции, если функциональные обязанности у всех остались прежние…
Я тоже так сначала подумал, но оказалось, что электроника там не предусмотрена.
Чуть выше привел выдержки из тендерной документации и приведенный там же образец.
Стол покрытие шпоном. Размеры 5200*2100*850 мм. Столешница стола изготовлена из экологически чистых материалов (сосна, березовая фанера). Фанеруется шпоном ценных пород дерева. Состоит из 2-х частей. Толщина столешницы 60мм. При покрытии изделия применяется износостойкий лак SAYERLACK (или эквивалент). Подстолье состоит из 6-ти ножек квадратного сечения. Ножки изготавливаются из столярного щита, фанеруется шпоном ценных пород дерева.
Образец
Т.к. glutton (англ. обжора), как правило, везде занят, а так же потому что покушать люблю очень, то стал gluttton, ну и для солидности, а потом мне это стало казаться ещё и более глазоприятным вариантом, начал писать с заглавной буквы: итого на выходе имеем — Gluttton.
P.S. Сижу на 11.2 KDE. Планировал перейти на 11.4 LXDE, но т.к. в KDE столько всего нового, а в LXDE «небольшие улучшения», то теперь вот и засомневался куда податься…
У нас сейчас там две группы в командировке и мы и посредник целый день не можем им на мобильные (местного оператора) дозвониться — девушка-робот на местном языке что то пытается объяснить.
В Monodevelop есть конкретно code metrics addin с похожими возможностями.
Например:
Пх. Тоже мне проблема. Да пусть переименовывают во что угодно.
P.S.Может заодно и мужика с фона уберут, а то он мне как то приелся.
Интересно, надо бы «поковырять» на досуге…
Что за глупости? Я совершенно не против ни MS ни тем более VS (особенно Express версии), хотя сам в последнее время перешел на Linux и работаю с Mono…
Не то что бы главное, скорее базовое — то с чего начинается построение. Я например могу себе представить CI без генерации документации, или без разворачивания приложения, на худой конец, даже без тестирования, но вто без checkout'а — с большим трудом.
Сначала, вы создаете проект, к нему тесты, создаете репозиторий, для хранения кода, затем скрипт, который выполняет сборку проекта и запускает тесты, а в заключении «цепляете» это скрипт на сервер интеграции.
Пожалуй да.
Непрерывная интеграция — процесс автоматический и в процессе сборки «кликов» быть не должно. «Клик» должен быть один —
«Сделать пи… ато»«Build».По сути вопроса, мне ответить нечего — я не знаю о наличии (равно как и об отстутствии) подобных plugin'ов. Просто не могу не поделиться опытом и не отметить тот факт, что использования plugin'ов без понимания сути больше зло чем добро. Это субьективно и основано исключительно на личном опыте (точнее сказать на личных ошибках). Если вы понимаете чего вы хотите от непрерывной интеграции, то plugin помочь может, а в противном случае, по моему мнению, наврятли. Хотя…
Уверен, что если возможность интегрирования в IDE реализована, то это полезно и востребовано. Но в то же время хотел бы предостеречь tangro от использования подобных решений. Возможно это излишнее занудство, но сначало нужно понять процесс изнутри, а уже затем использовать инструменты инкапсулирующие его и предоставляющие более удобный интерфейс.
Приведу несколько примеров.
Например некотрые IDE поддерживают интеграцию с VCS и глупо бы было бы не использовать хотя бы время от времени эту возможность. Но познавать VCS по этому плагину — это тернистый путь ведущий в никуда.
Ещё одним примером может стать замечательный инструмен для работами с БД Access. С его помощью можно достаточно быстро создавать простые БД и, что более важно, проектировать отчеты и формы. Опять же таки, было бы глупо, в подходящих случаях не использовать Access. Но изучать основы БД по Access, на мой взгляд, зло. Почитайте вопросы которые задают на форумах новички по Access и, напрмер, по MS SQL Server или MySQL…
Т.о., резюмируя, хочу категорически порекомендовать tangro покинуть уютное окружение любимой IDE и познакомиться с сторонними инструментами и только после получения некоторого опыта инкапсулировать те операции, содержание которых понятно посредством plugin'ов.
chaliy, спасибо за ссылку — расширю кругозор (тем более, что: «TeamCity now supports continuous integration builds on Windows and Unix-based platforms under Mono framework.»).
Мне очень сильно помогло на самом первом этапе для понимания основ вот эта статья: www.developers.org.ua/archives/jony/2009/06/16/dot-net-development-process/
К статье есть много вопросов, но для начала — самое то.
Но видать или из-за кривых рук или же от не знания профит от этого нулевой.
Связка репозиторий — багтрекер:
— возможность в Trac просматривать содержимое репозитория;
— возможность в Trac просматривать diff'ы.
Связка репозиторий — сервер интеграции:
— возможность в Hudson просматривать события произошедшие в репозитории в рамках build'ов.
Связка багтрекер — сервер интеграции:
— возможность быстрого перехода из сервера ингерации к тикету (если commit'ах в коментарий помещать номер тикета (например: «Fix defect #42.»), то Hudson преобразует их в ссылки и позволяет переходить по ним к тикету в Trac).
Это все те возможности, которыми я сумел овладеть. Буду признателен если, кто-нибудь поделиться опытом и поскажет, какую ещё выгоду можно извлечь от связки указанных инструментов.
Я использую NAnt.
Не думаю, что есть смысл запускать сборку после каждого коммита (особенно на начальной стадии проекта). Поэтому потеря не велика. Я тоже сначала ставил hook на коммит, но потом отказался от этой идеи и начал запускать сборку «в ручную» по факту закрытия тикета в багтрэкере (а у меня это не всегда один коммит).
Мне кажется, что автор старался, т.к. диаграммы выполнены в линиях разной толщины, надписи сделаны печатными буквами и нет следов подтираний и помарок.
Да и вообще, чего это я за автора «отдуваюсь», пусть он сам и скажет, в конце-концов!
Кстати, о методе представления «в карандаше»: www.websequencediagrams.com/
Наверное это хотел сказать автор статьи?
С очень похожим доводом у нас на предприятии (не связано с разработкой ПО) на последнем совещании вообще запретили использовать слово «контроль» — теперь только «сопровождение»! О как!
Хотя лично мне не понятно, как это может положительно повлиять на процесс изготовления продукции, если функциональные обязанности у всех остались прежние…
Просто, мысли в слух…
Чуть выше привел выдержки из тендерной документации и приведенный там же образец.
Образец