Сохраняйте корректность рабочего пространства Eclipse с непрерывной интеграцией

Question

Неправильная конфигурация IDE - большой источник неэффективного использования времени в нашей команде. Я хотел знать, пытались ли другие команды проверить работоспособность рабочего пространства eclipse с помощью непрерывной интеграции. Eclipse является открытым исходным кодом и расширяемым, и большинство (все?) Его файлов находятся в формате XML. Поэтому не составит труда добавить шаг к непрерывной интеграции, который проверяет работоспособность рабочей области, например, отсутствие отсутствующих Jar-файлов, ошибок и т. Д.

У нас есть отдельный ant-скрипт для реальных сборок, которые идут в QA и для клиентов. Этот муравейный скрипт выполняется с непрерывной интеграцией, и мы провели несколько простых проверок, которые перехватывают большинство больших шоу-стопперов.

Конфигурация рабочего пространства - это отдельная история, и мы иногда обнаруживаем проблемы, когда уже слишком поздно (разработчик ушел из дома).

РЕДАКТИРОВАТЬ: Обратите внимание, что мы предоставляем наши файлы конфигурации Eclipse.

Answer 1

Информация о сборке с помощью Eclipse из командной строки здесь .

(Должен быть комментарий, но я не могу).

Answer 2

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

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

Если сборка ломается из-за отсутствия фляги в сборке, добавьте проверку. Если сборка не работает из-за того, что она зависит от определенной функции в JVM, добавьте проверку.

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

Answer 3

Поскольку вы используете Ant, вы можете создать пользовательскую задачу, которая проверяет следующие файлы на соответствие заранее заданным. Если они не совпадают, сообщите о проблеме:

• workspace/.metadata/*.* (какие конфигурации вы считаете важными)
• workspace/project/.classpath
• workspace/project/.project
• workspace/project/.settings/*.* (какие конфигурации вы считаете важными)

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

Если вы хотите проверить только простые вещи, такие как «проект не компилируется», просто скомпилируйте проект в скрипте ant (используя javac task ) и посмотрите, есть ли ошибки.

Другое дело - непрерывная интеграция должна быть независимой от IDE. То есть у вас должна быть среда без IDE (CI Engine), которая компилирует проект. Представьте себе следующее:

• три разработчика, один из них случайно удалил банку из своего Eclipse, но проект в репозитории компилируется. Нет необходимости сообщать о проблемах в этом случае
• один из разработчиков добавляет новый jar и фиксирует. Другие не обновлены. О проблемах в рабочих пространствах не сообщается, хотя после обновления они могут получить проблему.

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