Комментарии 29
ну на 20 рабочих мест — пожалуй, пойдёт.
0
На самом деле, проблема возникает даже в масштабе 4-5 человек. gerrit в такой команде явный оверкилл будет, но вот всё остальное, уже актуально. А вот вопрос CI'я вообще не зависит от размера команды, а от числа и сложности ведомых конфигураций. Если два человека умудряются сопровождать два десятка инсталляций (по паре десятков серверов в каждой), то этой паре человек CI будет даже более актуален, чем ситуации «по три человека на инсталляцию».
Более того, как раз появление и отладка CI'я и открывает дорогу к «пара человек два десятка инсталляций обслуживает» — это и есть повышение эффективности труда.
Более того, как раз появление и отладка CI'я и открывает дорогу к «пара человек два десятка инсталляций обслуживает» — это и есть повышение эффективности труда.
+1
Вы рассказали что и как, а самое сложное при внедрении — обосновать почему. Вот здесь бы посерьёзнее акцент сделать. Либо поступать проще: обновлять резюме или выделяться из отдела в свою ОООшку, в которой всё делать по-уму и потом аутсорсить, гарантируя адекватное качество.
Вот как это обосновать? Как показать, что низкое качество постоянно ведёт к убыткам?
Вот как это обосновать? Как показать, что низкое качество постоянно ведёт к убыткам?
+1
Я не пытался написать статью «как внедрить». Это скорее оглавление по тому, что «можно/нужно внедрить». Потому что для меня интеграция code review с прохождением тестов была, например, внове. Что юнит-тесты перед приёмкой commit'а в центральный репозиторий могут запускаться, я знал, а вот так, чтобы CI голосовал «за» или «против» коммита, вместе с версионированными патч-сетами для одного и того же изменения — это для меня было неожиданно, и я вполне оценил как это круто.
Вопрос мотивации, соотношения рисков от внедрения (80% коллектива не понимает нафига это и как им пользоваться, а оставшийся 20% собирается ещё что-то накручивать поверх) — это совсем отдельная тема.
Насчёт «выделиться в ООО-шку» — не все процессы в компании могут быть так выделены, а да и не все стейкхолдеры захотят такое.
Аргументация для начальства, и взаимодействие с ним — тоже очень сложный отдельный разговор, потому что у начальства могут быть свои оценки полезности существования отдела, плюс дипломатия между отделами, плюс стоимость уже внедрённого (и, например, не используемого)…
Вопрос мотивации, соотношения рисков от внедрения (80% коллектива не понимает нафига это и как им пользоваться, а оставшийся 20% собирается ещё что-то накручивать поверх) — это совсем отдельная тема.
Насчёт «выделиться в ООО-шку» — не все процессы в компании могут быть так выделены, а да и не все стейкхолдеры захотят такое.
Аргументация для начальства, и взаимодействие с ним — тоже очень сложный отдельный разговор, потому что у начальства могут быть свои оценки полезности существования отдела, плюс дипломатия между отделами, плюс стоимость уже внедрённого (и, например, не используемого)…
+1
Похоже что Фабрикатор от Фейсбука покрывает, эсли не все, то большенство необходимых приложений
+3
Выглядит интересно, спасибо, посмотрю.
Но всё равно нет ни одного продукта, который бы лёг целиком под нужды компании. Обычно нюансы возникают в районе стыка бэкофиса и продакшена, и тут каждому приходится делать самому — потому что продакшен чаще всего это собственное ноу-хау, которое и есть бизнес компании, так что готового его в открытом доступе всё равно нет.
Но всё равно нет ни одного продукта, который бы лёг целиком под нужды компании. Обычно нюансы возникают в районе стыка бэкофиса и продакшена, и тут каждому приходится делать самому — потому что продакшен чаще всего это собственное ноу-хау, которое и есть бизнес компании, так что готового его в открытом доступе всё равно нет.
+1
Спасибо за стаью. Небольшое дополнение для тех команд, которые находятся в 2-х и более офисах/странах — имеет смысл поставить или подписаться на persistent chat, например www.hipchat.com
+1
А зачем городить огород этих решений, которые нужно поддерживать, когда можно просто использовать существующие сервисы?
HipChat + Jira + Confluence + GitHub + Travis-CI + Google Apps
HipChat + Jira + Confluence + GitHub + Travis-CI + Google Apps
0
А зачем покупать серверы, если можно арендовать в хецнере, линоде или амазоне? Своя инфраструктура все-таки надежней, и не канет в лету, как, к примеру, code spaces.
0
Поправлю — если уж используются решения Atlassian — JIRA и HipChat — то репозиторий уместнее держать на их же BitBucket. Интеграция с первыми двумя на порядок лучше гитхаба. + BitBucket позволяет делать code review в отличии от.
0
Часть вещей можно отдать на аутсорс, разумеется. Более того, jira/confluence/github в списке упомянуты. Но, например, билд-сервера всё равно придётся описывать в конфигурации/настраивать вручную, так же как и внедять использование этих средств. Настройка и место размещения — дело десятое.
А как вы этой связкой code review делать собираетесь?
А как вы этой связкой code review делать собираетесь?
0
У нас команды по парам (2 человека на фронт работ) и они принимают пулл реквесты друг друга.
Дело в том, что поднять jira не достаточно, время на её тюнинг и поддержку со временем будет потрачено больше, чем на установку. Мне кажется так же с остальными частями. Сам в свое время поставил её на свой инстанс, вышло дороже ondemand за хостинг DO, плюс переодический саппорт.
Дело в том, что поднять jira не достаточно, время на её тюнинг и поддержку со временем будет потрачено больше, чем на установку. Мне кажется так же с остальными частями. Сам в свое время поставил её на свой инстанс, вышло дороже ondemand за хостинг DO, плюс переодический саппорт.
0
То есть у вас пока стадия «pull requests». В принципе, до определённой сложности проектов это нормально, и так работает очень много компаний. Следующий шаг (обычно после двух-трёх странно принятых реквестов) — это формализованные системы code review.
Использование стандартизированных решений — огромная экономия. Когда стандартные решения применимы.
Использование стандартизированных решений — огромная экономия. Когда стандартные решения применимы.
0
можно обойтись 2-5 серверами (~200-300 т.р. на каждый) для всего, плюс отдельный бэкап-сервер.
Видимо мы в разной России с вами живем. Обычно это выглядит как: «вот вам 50тр на отдел, купите новый сервер, вместо Core 2 Duo десктопа, работающего с середины прошлого десятилетия. Больше денег нет, даже не просите.»
+2
Это уже совсем жуть какая-то. Даже в провинции в сфере образования не так все плохо.
+2
НЛО прилетело и опубликовало эту надпись здесь
Так, батенька, IT директора не зря деньги получают. Фонд ЗП сформирован, так что выделение ресурсов на создание — это вопрос правильных приоритетов. 50 т.р. достаточно для аренды серверов на длительное время, плюс обычно есть свои ресурсы (core2duo никто ж не выкидывает?). А дальше IT директор отчитается о значительном повышении эффективности труда, и внедрении дорогостоящей (в случае аутсорса) системы силами собственных сотрудников при практически нулевых затратах. В принципе, на фоне фонда заработной платы это в любом случае будут не очень большие деньги.
0
Отличие блога и использования страниц в вики не очень понятно. Вот, например, confulence по умолчанию это поддерживает, и можно как-то разделять и что-то писать во внутренний блог, а на что-то просто создавать страницы.
А так, да, если вики из коробки блог не поддерживает, лучше не городить ещё одну грядку в огороде, а заставлять просто писать в вики и считать это «блогом».
А так, да, если вики из коробки блог не поддерживает, лучше не городить ещё одну грядку в огороде, а заставлять просто писать в вики и считать это «блогом».
+1
принтер здесь не только для заявлений на отпуск. из опыта — намного проще распечатать тз (информативную часть с картинками), или схему бд и за круглым столом совместно на бумажке чиркать ручками/карандашами. Так что — маст хев, и бумаги к нему побольше, бумаги.
а насчет
GUI к ним кстати весьма полезен -от Syntevo в частности — SmartSvn/SmartGit. Мержить бранчи изо дня в день и разгребать конфликты лучше не вручную.
а насчет
Плюс у виндузятников свой мир, там что-то другоенеправда — те же svn/cvs/vcs/git/…
GUI к ним кстати весьма полезен -от Syntevo в частности — SmartSvn/SmartGit. Мержить бранчи изо дня в день и разгребать конфликты лучше не вручную.
0
Я помню, для windows были какие-то проприетарные системы версионирования, которые как-то совсем глубоко в visual studio интегрировались. Или оно сдохло? (Я не троллю, я просто не в курсе).
0
Visual Source Safe это когда-то называлось, теперь это Team Foundation Server, и оно много чего умеет помимо собственно контроля версий. Но я им как-то и не пользовался ни разу, не могу сказать ничего хорошего или плохого.
И кстати, git-репозиторий можно спокойно подключить к Team Foundation, вот статья например
И кстати, git-репозиторий можно спокойно подключить к Team Foundation, вот статья например
0
Perforce живее всех и он не только для Windows, да и git с hg прикручиваются к VS.
0
Visual SVN например есть
0
Эх, мечты, мечты…
0
Почему бы не использовать полный стек от Atlassian?
Лучше два, но при таких количествах сотрудников нельзя надеяться только на их квалификацию и порядочность. Подобная схема хорошо работает только в небольших командах до 20-30 человек, дальше личного контроля уже не хватает.
У себя почти всегда выступаю против закручивания гаек у профессиональных пользователей, но некоторые «корпоративные заморочки» могут быть полезны и экономить время сотрудников — тот же BigFix с каталогом приложений или непрерывный бекап рабочей станции в FastBack.
компьютер с кнопками (порядка 90-100 шт) на каждое рабочее место
Лучше два, но при таких количествах сотрудников нельзя надеяться только на их квалификацию и порядочность. Подобная схема хорошо работает только в небольших командах до 20-30 человек, дальше личного контроля уже не хватает.
У себя почти всегда выступаю против закручивания гаек у профессиональных пользователей, но некоторые «корпоративные заморочки» могут быть полезны и экономить время сотрудников — тот же BigFix с каталогом приложений или непрерывный бекап рабочей станции в FastBack.
0
В больших командах должна быть бóльшая автономность. Гайки закручивают в тот момент, когда начинают терять управление — и закручивание гаек это «last hope». На самом деле, чем больше формальных KPI накладывается на команду и её членов, тем большие шансы, что в этой системе останутся те, кто могут показывать формальные KPI и соблюдать ритуалы, а не делать дело.
Оставляя в стороне работу с коммерческой тайной (всё равно там всё на честности держится, хотя формально — типа, секьюрити и всё такое), для обычной компании нет ни малейших методов защититься от сотрудника. Так что вместо того, чтобы натыкивать брёвна поперёк дороги (забора всё равно не получится) лучше не мешать, и обеспечивать лояльность.
Заметим, между отделами могут (и должны быть) формализованные отношения, но они не должны спускаться на индивидуальный уровень внутри команды.
Оставляя в стороне работу с коммерческой тайной (всё равно там всё на честности держится, хотя формально — типа, секьюрити и всё такое), для обычной компании нет ни малейших методов защититься от сотрудника. Так что вместо того, чтобы натыкивать брёвна поперёк дороги (забора всё равно не получится) лучше не мешать, и обеспечивать лояльность.
Заметим, между отделами могут (и должны быть) формализованные отношения, но они не должны спускаться на индивидуальный уровень внутри команды.
0
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Современный бэк-офис IT-компании