Назад | Перейти на главную страницу

Подготовка рабочего стола для небольшой команды разработчиков программного обеспечения Linux

Цель: Получите небольшую команду, использующую стандартный образ для разработки, а не 4 разработчика программного обеспечения, создающих свои собственные среды.

Зачем:

  1. требуется день или дни, чтобы установить дистрибутив, библиотеки, специфичные для сборки, такие инструменты, как редакторы и IDE, mysql, couchdb, java, maven, python, android-sdk и т. д. Это гигантский PITA, который при повторении 4 раза четырьмя разработчиками (не системные администраторы) тратят время и порождают раздражающие расхождения, которые возникают позже (синдром it-build-on-my-box).

  2. Нет обмена продуктивностью, настройками, трюками, скриптами, настройками.

Отчасти этому помогает разделение систем сборки на безголовые образы виртуальных боксов. Это на самом деле не относится к инструментам или разработчику GUI-рабочего стола, который нужно делать.

Итак, я вижу три основные стратегии: привидение, виртуализацию и, наконец, создание своего рода собственного дистрибутива Linux (я думаю, что Google делает что-то вроде этого).

Целевая среда разработки основана на Debian OpenBox и должна позволять сочетанию ноутбуков Core i7 3-го поколения с минимум 8 ГБ работать как с одной, так и с несколькими головками. Важно то, что лаппи не то же самое, но смесь MacBook и ПК 2012 года выпуска. Так:

  1. виртуализация: выполняет всю вашу работу в виртуальной машине, например VirtualBox, практично на этом оборудовании или раздражает.

  2. ореолы: будут ли ноутбуки разных производителей делать это непрактичным.

  3. Дистрибутив «сделай сам»: если не считать сценариев установки кучи пакетов, я не знаю, есть ли какой-нибудь «производитель дистрибутива», который мог бы помешать этому проекту стать эпическим проектом установки пакетов сценариев.

Итак, какой совет?

Это сложная проблема, и она очень, очень быстро проникает прямо в политическую жизнь. Если корпоративная культура очень сильна в духе «разработчики создают свои собственные, это то, как они наиболее продуктивны», вены, которые невозможно взломать. Однако, поскольку ИТ-специалисты определенно участвуют, по крайней мере, в начальной настройке, похоже, что вы не так уж далеко в кроличьей норе.

У меня аналогичная проблема, хотя все, что связано с ИТ, - это самая простая настройка нового ноутбука. я не участвуя в настройке среды разработки, каждый разработчик отвечает за это (что быстро превращается в командную работу, что по-своему хорошо).


Однако без явной поддержки со стороны руководства все, что вы делаете, будет зависеть от убеждения поддерживаемых пользователей в том, что то, что вы делаете, - к лучшему. Этому навыку мы не можем научить.


В силу характера нашей работы мы обнаружили, что разработка, ориентированная на виртуальные машины, работает очень хорошо. Поскольку у нас также есть смесь ноутбуков с OS X, Windows и Linux в качестве станций разработки, и мы развиваемся в направлении гораздо более конкретной комбинации инструментов и ОС, виртуальные машины - самый надежный способ быть уверенным, что новый код будет работать на целевая платформа.

Раньше у нас были люди, которые разрабатывали на MacBook, развертывали в среде интеграции, а затем проводили несколько дней, работая над специфическими для Mac причудами, которые не работают в целевой среде. Эта проблема «потратить несколько дней» исчезла, когда эти пользователи начали использовать виртуальные машины.

Подойдет ли вам рабочий процесс, ориентированный на виртуальные машины, во многом зависит от ваших практик разработки. Кажется, это работает лучше всего, если разработчик:

  • Может ли разработчик работать над функциональной веткой
  • Может легко развернуть эту функциональную ветвь на свой собственный набор виртуальных машин.
  • Может с одинаковой легкостью объединить свою функциональную ветвь с интеграцией / тестированием / qa и с минимальной настройкой
  • Обладает достаточным чувством стиля, чтобы не злить других разработчиков

Что касается «GUI IDE в виртуальной машине», это тоже может работать. Некоторые из наших пользователей Mac идут именно по этому пути: у них есть полноэкранная виртуальная машина на одном экране, на которой они создают весь свой код и используют другие экраны для вещей, не связанных с разработкой, таких как просмотр stackoverflow для ответов. Это лучше всего работает, если буфер обмена можно переносить между настольным компьютером и виртуальной машиной.

Хороший план на данный момент - создать виртуальную машину на любой платформе, которую вы используете, со всеми преимуществами, которые вы всегда добавляете в свои свежие сборки. Затем подключите их, чтобы получать обновления из репозитория, размещенного вами, чтобы вы могли лучше управлять тем, какое программное обеспечение обновляется, когда и у вас меньше сползания версий. Для достижения наилучшего эффекта включите некоторые настройки, которые кажутся общими для некоторых разработчиков, так как это упростит битву сердец и умов.

Вы боретесь с укоренившимися практиками, и всегда нужно время, чтобы это изменить. По крайней мере, без приказа Сверху.