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