Комментарии 39
Все это круто, но лучше подскажите как настроить имейл, заведенный в дневнике по протоколу pop3 или imap? Чегой-то я не нашел, пришлось делать перенаправление на другой ящик, а это уже не то. У дочки смартфон и было бы намного удобней напрямую пользоваться ящиком дневника и отвечать через него. У нас пока Дневник не особо используется, вернее только начинают им пользоваться и все время заходить на сайт смотреть что там нового, а нового там (по учебе) практически ничего, как-то не алё. Кстати, было бы еще круче сделать мобильную версию как раз для смартфонов, ибо удобно именно для учеников.
Сейчас это сервис live@edu, настроить можно так blog.dabasinskas.net/configuring-liveedu-access-via-pop3imap/
Скоро будет миграция на Office 365, там будет немного по другому возможно
Мобильная версия для Android, WP8 и iOS сейчас в разработке, и в этом полугодии мы ожидаем релиз
Скоро будет миграция на Office 365, там будет немного по другому возможно
Мобильная версия для Android, WP8 и iOS сейчас в разработке, и в этом полугодии мы ожидаем релиз
Спасибо. И отличная новость про мобильный клиент
А, эти настройки я видел. Не работают. И так пробовал и эдак — никак не хочет пароль опознавать, хотя в веб интерфейсе все нормально воспринимается (вернее после перенаправления с дневника)
Вот автор очень не любит OSS. Как и ребята из MS, которые почему-то никогда не могут с первого раза написать что-то, что будет полностью соответствовать общепринятым мировым, но увы OSS, стандартам. Попробуйте подключиться через последнюю версию Outlook — я не удивлюсь, если заработает.
Вот еще! У меня thunderbird стоит с настроенными пятью ящиками, и ради одного, редко используемого ставить оутлук я не собираюсь. Тем более, что хотел настроить еще на андроиде как моем, так и дочери. Тады уж пусть остается как есть.
Я люблю и пользуюсь OSS. Но только там где это необходимо, и где это решает проблему максимально эффективно.
Имхуется мне, народ читает между строк тот тезис. Видит «OSS для бедных» и начинает изображать негодование=)))
Имхуется мне, народ читает между строк тот тезис. Видит «OSS для бедных» и начинает изображать негодование=)))
Есть разные подходы к OSS. Конечно, ни одному адекватному человеку не придёт в голову писать что-то на ActiveX для браузеров в 2013 году. Если вам нужно разработать какое-то браузерное приложение — вы вынуждены использовать OSS. Конечно, если вы идёте не по простому пути, а по правильному. Есть масса сфер, в которых без OSS просто никуда.
Однако для меня использовать OSS необходимо в 100% случаев, если это в принципе возможно и позволяет решить поставленные задачи. Я уже много раз убеждался, что доп. затраты во времени, необходимые на внедрение OSS, практически всегда окупаются стабильностью дальнейшей работы. Да, я активно использую проприетарщину. Там, где без неё не обойтись. Но только после того, как убеждаюсь, что OSS аналогов нету, или они мне не подходят из-за их функционала.
Собственно, проблема отношения M$ к IMAP наглядно иллюстрирует все «плюсы» проприетарных продуктов. Я до сих пор в шоке от Exchange 2003 и Outlook 2003. Что с серверной стороны, что с клиентской был такой ахтунг, что диву даёшься. Как можно было крупнейшей софтовой корпорации умудриться написать худший IMAP клиент и худший IMAP сервер на тот момент — для меня загадка. Я не знаю, как дела обстоят сейчас. Я разработал удобное и простое решение на базе Dovecot и Postfix с полной интеграцией с AD и уже много лет внедряю его везде, где мне нужно поднять почту. И удивительно: никаких проблем больше у меня не было. Я потратил достаточно много времени на разработку своей системы, но она работает, как часики, постоянно обновляясь и лишь немного изменяясь. И самое главное — я уверен, что она будет работать ещё много-много лет. И никакие плюшки новых Exchange не заставят меня перейти на продукты MS до тех пор, пока мне будет хватать функционала моего почтовика. Просто потому, что я знаю на личном опыте, что MS не в состоянии выпустить продукт, который легко интегрируется со сторонними системами, так что используя Exchange я всегда рискую нарваться на несовместимость какого-нибудь очередного IMAP клиента, который мне понадобится.
Проприетарное — это практически всегда означает худшую архитектуру, а значит стабильность и масштабируемость, худшую поддержку сторонних стандартов, а значит проблемы с интеграцией. Просто из-за разницы подходов: для коммерческих продуктов важно удобство и функционал, а для OSS — правильная архитектура и соответствие стандартам. Я выбираю второе, ибо первое ко второму всегда можно добавить самостоятельно, причём чаще всего — потратив на это не так и много времени. Вы выбираете первое — потому что вам нужен готовый, оттестированный и хорошо работающий продукт. Мои издержки — лишь время на внедрение, ваши — практически точно отсутствующая возможность расширения и эволюционирования ваших систем за рамки софта от какой-то одной фирмы и связанных проприетарных технологий.
Однако для меня использовать OSS необходимо в 100% случаев, если это в принципе возможно и позволяет решить поставленные задачи. Я уже много раз убеждался, что доп. затраты во времени, необходимые на внедрение OSS, практически всегда окупаются стабильностью дальнейшей работы. Да, я активно использую проприетарщину. Там, где без неё не обойтись. Но только после того, как убеждаюсь, что OSS аналогов нету, или они мне не подходят из-за их функционала.
Собственно, проблема отношения M$ к IMAP наглядно иллюстрирует все «плюсы» проприетарных продуктов. Я до сих пор в шоке от Exchange 2003 и Outlook 2003. Что с серверной стороны, что с клиентской был такой ахтунг, что диву даёшься. Как можно было крупнейшей софтовой корпорации умудриться написать худший IMAP клиент и худший IMAP сервер на тот момент — для меня загадка. Я не знаю, как дела обстоят сейчас. Я разработал удобное и простое решение на базе Dovecot и Postfix с полной интеграцией с AD и уже много лет внедряю его везде, где мне нужно поднять почту. И удивительно: никаких проблем больше у меня не было. Я потратил достаточно много времени на разработку своей системы, но она работает, как часики, постоянно обновляясь и лишь немного изменяясь. И самое главное — я уверен, что она будет работать ещё много-много лет. И никакие плюшки новых Exchange не заставят меня перейти на продукты MS до тех пор, пока мне будет хватать функционала моего почтовика. Просто потому, что я знаю на личном опыте, что MS не в состоянии выпустить продукт, который легко интегрируется со сторонними системами, так что используя Exchange я всегда рискую нарваться на несовместимость какого-нибудь очередного IMAP клиента, который мне понадобится.
Проприетарное — это практически всегда означает худшую архитектуру, а значит стабильность и масштабируемость, худшую поддержку сторонних стандартов, а значит проблемы с интеграцией. Просто из-за разницы подходов: для коммерческих продуктов важно удобство и функционал, а для OSS — правильная архитектура и соответствие стандартам. Я выбираю второе, ибо первое ко второму всегда можно добавить самостоятельно, причём чаще всего — потратив на это не так и много времени. Вы выбираете первое — потому что вам нужен готовый, оттестированный и хорошо работающий продукт. Мои издержки — лишь время на внедрение, ваши — практически точно отсутствующая возможность расширения и эволюционирования ваших систем за рамки софта от какой-то одной фирмы и связанных проприетарных технологий.
Но, тем не менее большинство компаний живёт на Exchange, маздае, офисе, и весьма хорошо
Но это скорее риторическая полемика. Я не фанат мелкософта, я не фанат жабы, пыхи и ещё многих вещей в том числе IT=)))). Это даёт мне возможность подходить к выбору технологии объективно, я просто смотрю, что решит мою проблему максимально эффективно и не породит кучи рисков сейчас и в будущем. Именно поэтому для кэша мы используем Redis а не App Fabric (ну отстой же реально), для UI тестов watir и cucumber (а это Ruby, хотя вся контора состоит из дот нетчиков) а нет Coded UI или другие фреймворки для Selenium на .Net и т.д.
Но это скорее риторическая полемика. Я не фанат мелкософта, я не фанат жабы, пыхи и ещё многих вещей в том числе IT=)))). Это даёт мне возможность подходить к выбору технологии объективно, я просто смотрю, что решит мою проблему максимально эффективно и не породит кучи рисков сейчас и в будущем. Именно поэтому для кэша мы используем Redis а не App Fabric (ну отстой же реально), для UI тестов watir и cucumber (а это Ruby, хотя вся контора состоит из дот нетчиков) а нет Coded UI или другие фреймворки для Selenium на .Net и т.д.
Вот это правильно, но такая позиция плохо прослеживается в вашей статье)
Ну и с Exchange вы явно загнули — большинство компаний на нём не живёт) У меня вот ни у одного знакомого сисадмина экса нету. Правда все обслуживают небольшие фирмы (до 100 человек), но с другой стороны мелкие фирмы — это и есть подавляющая часть российского бизнеса) Без винды, конечно, ни туды, и ни сюды.
Ну и с Exchange вы явно загнули — большинство компаний на нём не живёт) У меня вот ни у одного знакомого сисадмина экса нету. Правда все обслуживают небольшие фирмы (до 100 человек), но с другой стороны мелкие фирмы — это и есть подавляющая часть российского бизнеса) Без винды, конечно, ни туды, и ни сюды.
Статья была не про мою личность и отношение к IT, а про CI=))))
Я всю свою карьеру работал только с европой и америкой и некоторыми Русскими компаниями. Большие корпорации (> 40к сотрудников), маленькие (до 10к)
корпорации, средние… 90% из них сидит на Exchange. Остальные на Lotus Notes (страх и ужос) или чём то другом. Про мелкий бизнес я сказать не могу, это да.
Я всю свою карьеру работал только с европой и америкой и некоторыми Русскими компаниями. Большие корпорации (> 40к сотрудников), маленькие (до 10к)
корпорации, средние… 90% из них сидит на Exchange. Остальные на Lotus Notes (страх и ужос) или чём то другом. Про мелкий бизнес я сказать не могу, это да.
Вы слишком предвзяты по отношению к Jenkins — сам недавно занимался миграцией с CCNET на Jenkins. Основная масса общеиспользуемых плагинов написана и поддерживается разработчиками Jenkins, эти плагины достаточно оттестированы и стабильно работают. Что касается плагинов сторонних разработчиков — конечно, есть вероятность что что-то пойдет не так, но у вас есть возможность зарепортить багу либо скачать исходники плагина и самому все пофиксить, ну на крайний случай есть возможность заказать платный фикс конкретной баги(назначив соответсвующую цену).
Я не предвзят, я знаю что всё можно сделать. Задачи, которые я решал можно решить и на Jenkins и на CCNET. Весь вопрос в скорости, качестве, простоте поддержки и заделах на будущее. Жертвовать скоростью и качеством, но получать возможность что то там допилить и пофиксить потому что open source порождает очевидные риски, которыя я, как ответственный за внедрение этой методологии решил смитигировать используя Team City, и ни разу не пожалел. Это дало мне boost и время, на то что бы оперативно обучить сотрудников Team City, и заняться внедрением остальных практик, db projects, code review, static analysis и другое.
Ну и кроме того, feedback коллег по цеху, которые стали пользоваться Team City лучший показатель правильности выбора. А он был очень положительный, и этим реально пользуются
Ну и кроме того, feedback коллег по цеху, которые стали пользоваться Team City лучший показатель правильности выбора. А он был очень положительный, и этим реально пользуются
Не понимаю о какой «скорости» идёт речь?
Гонка поднять Jenkins (whatever tool) за час или за два?
Да хоть за целый день поднимай и настраивай. Важно, что это будет поднято в обозримые сроки (день-два) и будет работать намного дольше (год, например).
Кстати, поднять jenkins с «джентльменским набором плагинов» — это 30 минут. При этом, там тоже всё очень просто.
Если настройка CI серверов (не процесса) у вас занимает больше двух дней — вы делаете что-то не так, пора открыть доки ;)
По существу, вам в проекте не только ведь build нужен. Кстати, если не хочется ставить плагин — можно не ставить. Всё равно всё сводится к msbuild.exe myproject.sln
Есть ещё 100500 задач, которые возлагаются на CI+CD (Continues Integration + Continues Delivery). Может оказаться, что коммерческое решение не способно быстро адаптироваться под ваши задачи или предоставить workaround.
Кстати, возник вопрос про две задачи: msbuild (который идёт 2 минуты)+asp.build (20 минут) и плюсуем сюда какие-нибудь интеграционные тесты, которые вы тоже захотите запускать, которые будут идти час. Ситуация:
1. Dev1 коммитит код -> запускается msbuild
2. Запускается asp.net следом
3. Dev1 опять коммит (asp.net не собрался ещё)
4. Dev2 Dev3 и Dev4 тоже коммитят с интервалом в 5 минут
У вас выстраивается очередь на сборку всех коммитов в asp build или только последний. Сам столкнулся с этой ситуацией.
Если есть довольно длинный «build pipeline» в конечной точке будет накапливаться очередь и можно прийти к тому, что коммиты будут идти чаще чем система сможет их собирать.
Я решил эту проблему разрывом pipeline и запуском следующих стадий через интервал больший, чем требует стадия.
ПС. Современные инструменты на сегодняшний день уже достаточно мощные и многое умеют. Поэтому, куда больший интерес представляет выработанные процессы на проекте. Branching workflow, Deployment workflow, Testing workflow, QA Releases, Hotfixes, Rollbacks. От проекта к проекту эти вещи сильно отличаются.
Гонка поднять Jenkins (whatever tool) за час или за два?
Да хоть за целый день поднимай и настраивай. Важно, что это будет поднято в обозримые сроки (день-два) и будет работать намного дольше (год, например).
Кстати, поднять jenkins с «джентльменским набором плагинов» — это 30 минут. При этом, там тоже всё очень просто.
Если настройка CI серверов (не процесса) у вас занимает больше двух дней — вы делаете что-то не так, пора открыть доки ;)
По существу, вам в проекте не только ведь build нужен. Кстати, если не хочется ставить плагин — можно не ставить. Всё равно всё сводится к msbuild.exe myproject.sln
Есть ещё 100500 задач, которые возлагаются на CI+CD (Continues Integration + Continues Delivery). Может оказаться, что коммерческое решение не способно быстро адаптироваться под ваши задачи или предоставить workaround.
Кстати, возник вопрос про две задачи: msbuild (который идёт 2 минуты)+asp.build (20 минут) и плюсуем сюда какие-нибудь интеграционные тесты, которые вы тоже захотите запускать, которые будут идти час. Ситуация:
1. Dev1 коммитит код -> запускается msbuild
2. Запускается asp.net следом
3. Dev1 опять коммит (asp.net не собрался ещё)
4. Dev2 Dev3 и Dev4 тоже коммитят с интервалом в 5 минут
У вас выстраивается очередь на сборку всех коммитов в asp build или только последний. Сам столкнулся с этой ситуацией.
Если есть довольно длинный «build pipeline» в конечной точке будет накапливаться очередь и можно прийти к тому, что коммиты будут идти чаще чем система сможет их собирать.
Я решил эту проблему разрывом pipeline и запуском следующих стадий через интервал больший, чем требует стадия.
ПС. Современные инструменты на сегодняшний день уже достаточно мощные и многое умеют. Поэтому, куда больший интерес представляет выработанные процессы на проекте. Branching workflow, Deployment workflow, Testing workflow, QA Releases, Hotfixes, Rollbacks. От проекта к проекту эти вещи сильно отличаются.
Кстати, поднять jenkins с «джентльменским набором плагинов» — это 30 минут. При этом, там тоже всё очень просто.
Отлично, только мне надо не просто поднять, а внедрить, автоматизировать кучу процессов, всё описать, всех обучить, прикрутить авто деплой, авто тесты, интеграцию с другими системами (issue tracker, ldap, wiki еtc) и реализовать кучу всяких идей возникших по ходу Как результат мы получаем франкенштейна, которого дорого поддерживать, сложно дальше модифицировать и т.д.
Team City я выбрал не потому что, типа клёво. А потому что он отвечал моим текущим потребностям без необходимости возиться с плагинами и настройкой, и отвечал моим идеям «на будущее»
Кстати, возник вопрос про две задачи: msbuild (который идёт 2 минуты)+asp.build (20 минут) и плюсуем сюда какие-нибудь интеграционные тесты, которые вы тоже захотите запускать, которые будут идти час. Ситуация:
1. Dev1 коммитит код -> запускается msbuild
2. Запускается asp.net следом
3. Dev1 опять коммит (asp.net не собрался ещё)
4. Dev2 Dev3 и Dev4 тоже коммитят с интервалом в 5 минут
Я не понял проблемы, интеграционные билды идут параллельно, параллельно же идут и asp.net compile
Суть в том, что бы проверять каждый коммит, и быстро понимать кто напортачил. Коммитятся у нас часто, очередь на 5 билд серверов не забивается. Это при том, что ещё есть интеграционные билды схемы базы данных (которые занимают по 30 минут=)
Кстати, немного «пооптимизировав» я снизил время на asp.net compile до 10 минут.
Может оказаться, что коммерческое решение не способно быстро адаптироваться под ваши задачи или предоставить workaround.
Всё может быть=) Пока такой проблемы не возникло, все счастливы. Возникнет — найдём решение.
Поэтому, куда больший интерес представляет выработанные процессы на проекте. Branching workflow, Deployment workflow, Testing workflow, QA Releases, Hotfixes, Rollbacks. От проекта к проекту эти вещи сильно отличаются.
Конечно, про это я отдельные статьи напишу
Буквально месяц назад впервые поднимал jenkins для пары rails проектов. Ни одной проблемы не возникло. Всё работает как часы, автосборка, тесты, нотификации, интеграция с redmine, автодеплой на стейджинг и ручной деплой на продакшен, сотрудники буквально писают кипятком от радости. И всё это я, не работая перед этим с CI вообще ни разу, настроил часа за 2-4. Теперь не представляю, как я раньше жил без jenkins.
Так что, может быть, у jenkins есть баги только для венды (хотя, не удивительно, думаю, доля windows-установок jenkins состовляет 1-5%).
Так что, может быть, у jenkins есть баги только для венды (хотя, не удивительно, думаю, доля windows-установок jenkins состовляет 1-5%).
И у меня тоже небыло никаких значимых проблем с плагинами у дженкинса.
Ну видимо для «не бедных» и модных это Майкрософт, Эппл и ТимСити… ;)
Ну видимо для «не бедных» и модных это Майкрософт, Эппл и ТимСити… ;)
Леший с ним с CI, но даже прочитав вашу преамбулу никак не могу пройти мимо фразы «OSS для бедных». Jenkins имеет понятные недостатки по сравнению с коммерческими решениями, да, тут вы достаточно убедительны. Но OSS альтернативы в других областях всё же очень часто превосходят проприетарное ПО по совокупности параметров, включающих в себя вопросы функционала и стабильности. Речь конечно не идёт о таких монстрах, как VS, хотя и он не идеален и имеет массу специфических недостатков по сравнению с некоторыми OSS альтернативами. Но блин, перечислять OSS продукты, которые очевидно лучше и надежней аналогов, можно очень долго. Чтобы статья не выглядела, как реклама продукта, и не провоцировала холивар — просто не надо употреблять сомнительные неаргументированные фразы, направленные на дискредитацию каких-либо технологий/продуктов и т.п. А то тут только недавно была новость про Opera, смысл которой в том, что проприетарный продукт в условиях достаточной конкуренции и востребованности своей сферы в принципе никогда не может быть лучше OSS. Собственно, Opera лишь подтвердила этот очевидный факт, давным-давно установленный многими другими OSS решениями. Я понимаю, что сфера CI очень специфична и явно никогда не будет столь же востребована, как браузеры ;) Да и конкуренция в ней небольшая — вот платные продукты и превосходит OSS решения, развиваемые в основном энтузиастами. Но говорить так обо всём OSS софте мягко говоря неправильно.
Советую перечитать мой тезис на этот счёт=)))
Я могу точно сказать, и вы скорее всего согласитесь, что качественные OSS-продукты проигрывают качественным же пропиеритарным решениям в двух важных вещах: стоимости поддержки и уровне сервиса.
it depends=) в бизнесе всё меряется баблом, куча компаний, с которыми я работал, как правило предпочитала платные решения в ядре бизнеса бесплатным, даже если платные хуже, даже если в них нет кучи свистелок перделок которые есть в бесплатном. Причина банальна и проста до безобразия — риски сбоев и простоев. Кому идти предъявлять претензии в случае факапа с business critical системой из за использования OSS? Коммьюнити? Авторам? Да они починят, да, может быть даже быстро. Но кто возместит потери денег из за простоя бизнеса? В случае проприетарщины, вендоров поделки всегда можно нагнуть на деньги, что успешно и делается. В не business critical системах ок, OSS ещё никого не убил, если он лучше платных аналогов конечно=)
Пример крупного проекта на основе OpenSource-инструментов: habrahabr.ru/post/168451/
Цитата: «CI Jenkins на шести серверах, три СУБД, два семейства ОС и три браузера под которые пишем продукт.»
Цитата: «CI Jenkins на шести серверах, три СУБД, два семейства ОС и три браузера под которые пишем продукт.»
Александр, я не совсем понял вашу идею про встроенный nuget-сервер в TeamCity.
Зачем своим сервером заменять стандартный сервер nuget.org?
«Залить в svn всё необходимые пакеты» — у меня никогда бы рука не поднялась, это в корне убивает идею nuget.
Очевидно же — если, например, выйдет новая версия jQuery, то первым делом она появится на nuget.org, в официальном репозитории.
Пакет не обновится в вашем личном уютном репозитории, пока вы сами не зальёте новую версию в svn.
По сути вам nuget и не нужен — в svn вместо nuget пакетов заливайте сразу dll и референсите на них — фактически у вас именно это и сделано, только с тонкой nuget-прослойкой.
Nuget-пакеты в svn заливать однозначно не надо.
Надо личный nuget-репозиторий использовать строго в дополнение к официальному, не заменяя его.
Пресекать же бесконтрольное добавление зависимостей в solution надо другим способом — введением контроля.
Например, перед добавлением новой зависимости советоваться с teamlead или архитектором.
Стороняя либа может не проходить по лицензии — вон у вас на скриншоте EPPlus — а ведь она до третьей версии шла по GPLv2 и вы не могли её использовать в коммерческом проекте.
Принимать решения о включении в проект сторонних либ должен человек наделённый соответствующими правами и ответственностью, вот и всё.
Зачем своим сервером заменять стандартный сервер nuget.org?
«Залить в svn всё необходимые пакеты» — у меня никогда бы рука не поднялась, это в корне убивает идею nuget.
Очевидно же — если, например, выйдет новая версия jQuery, то первым делом она появится на nuget.org, в официальном репозитории.
Пакет не обновится в вашем личном уютном репозитории, пока вы сами не зальёте новую версию в svn.
По сути вам nuget и не нужен — в svn вместо nuget пакетов заливайте сразу dll и референсите на них — фактически у вас именно это и сделано, только с тонкой nuget-прослойкой.
Nuget-пакеты в svn заливать однозначно не надо.
Надо личный nuget-репозиторий использовать строго в дополнение к официальному, не заменяя его.
Пресекать же бесконтрольное добавление зависимостей в solution надо другим способом — введением контроля.
Например, перед добавлением новой зависимости советоваться с teamlead или архитектором.
Стороняя либа может не проходить по лицензии — вон у вас на скриншоте EPPlus — а ведь она до третьей версии шла по GPLv2 и вы не могли её использовать в коммерческом проекте.
Принимать решения о включении в проект сторонних либ должен человек наделённый соответствующими правами и ответственностью, вот и всё.
Это верно отчасти. В любом административном контроле есть flaw by default — это человеческий фактор. Поэтому, для снижения рисков, любой административный контроль должен быть подкреплён техническими средствами. Можете считать это защитой от дурака.
Ну и кроме того, есть ряд кейсов которые требуют перевести всё на корпоративный nuget сервер
1) Nuget.org может упасть. И это было за последние три месяца несколько раз.
2) Доступ в интернет может отключится, и это тоже риск, который я митигирую
3) Билд машины могут не иметь выхода в интернет по security policy, я такое видел и не раз, не исключаю, что может быть внедрено и у нас. Мы работаем с персональными данными пользователей как никак и обязаны соблюдать законодательство РФ на этот счёт (а там бывают такие вещи, что диву даёшься), поэтому с security у нас всё строго. И это применимо не только к РФ, проект дневник представлен в ряде стран, у которых работа с персональными данными регламентируется ещё жёсче
4) Защита от дурака. Nuff said, это защита от риска человеческого фактора, как я уже сказал.
O'rly? Это чей то закон?=)))
Во первых это был пример для статьи, я не буду сюда писать, что реально используется. Во вторых, это уже 3я версия, поэтому можно использовать. В чём проблема?
Это позволило мне достичь цели. Если рука не поднимается… ну можно записаться на курсы повышения уверенности в себе.
Ну и кроме того, есть ряд кейсов которые требуют перевести всё на корпоративный nuget сервер
1) Nuget.org может упасть. И это было за последние три месяца несколько раз.
2) Доступ в интернет может отключится, и это тоже риск, который я митигирую
3) Билд машины могут не иметь выхода в интернет по security policy, я такое видел и не раз, не исключаю, что может быть внедрено и у нас. Мы работаем с персональными данными пользователей как никак и обязаны соблюдать законодательство РФ на этот счёт (а там бывают такие вещи, что диву даёшься), поэтому с security у нас всё строго. И это применимо не только к РФ, проект дневник представлен в ряде стран, у которых работа с персональными данными регламентируется ещё жёсче
4) Защита от дурака. Nuff said, это защита от риска человеческого фактора, как я уже сказал.
Nuget-пакеты в svn заливать однозначно не надо.
O'rly? Это чей то закон?=)))
EPPlus — а ведь она до третьей версии шла по GPLv2 и вы не могли её использовать в коммерческом проекте
Во первых это был пример для статьи, я не буду сюда писать, что реально используется. Во вторых, это уже 3я версия, поэтому можно использовать. В чём проблема?
у меня никогда бы рука не поднялась, это в корне убивает идею nuget.
Это позволило мне достичь цели. Если рука не поднимается… ну можно записаться на курсы повышения уверенности в себе.
Скомкано и сумбурно изложено…
Вывод только такой у меня: Автор молодец, что поставил процесс. Автор знаком немного с Jenkins и очень хорошо с TeamCity, отсюда и выбор инструмента.
О чем статья то???
Вывод только такой у меня: Автор молодец, что поставил процесс. Автор знаком немного с Jenkins и очень хорошо с TeamCity, отсюда и выбор инструмента.
О чем статья то???
РасскАжите о интеграции с багтрекером, тасктрекером, ревью и автоматическим тестированием?
Это лучше сделаем отдельной статьей, но у нас тут уже очередь оооочень интересных тем на подходе, так что закупайте попкорн ;)
Я и имел в виду отдельную статью :-)
А новые темы про CI будут?
А новые темы про CI будут?
Конечно, мы весело прикручивали авто деплой, cucumber и grunt к CI например
Будут =) Чем выше рейтинг статьи, тем быстрее сделаем следующую =)
А о чем еще вы хотите почитать? у нас же есть опыт создания портала, где 6000 000 пользователей только в РФ. Мы один из уникальных партнеров MSа в связи с этим
А о чем еще вы хотите почитать? у нас же есть опыт создания портала, где 6000 000 пользователей только в РФ. Мы один из уникальных партнеров MSа в связи с этим
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Continuous Integration в Дневник.ру