Почему у моей группы разработчиков должен быть сервер сборки?
Я думаю, что вам может потребоваться позвонить loadPixels() перед выполнением модификации и updatePixels() после выполнения модификации.
Из ссылка :
PImage myImage;
int halfImage;
void setup() {
size(100, 100);
halfImage = width * height/2;
myImage = loadImage("apples.jpg");
myImage.loadPixels();
for (int i = 0; i < halfImage; i++) {
myImage.pixels[i+halfImage] = myImage.pixels[i];
}
myImage.updatePixels();
}
void draw() {
image(myImage, 0, 0);
}
8 ответов
Существует несколько причин для использования серверов сборки. Не в определенном порядке и не в моей голове:
-
Вы упростите рабочий процесс разработчиков и уменьшите вероятность ошибок. Ваш сервер сборки может позаботиться о нескольких шагах, таких как проверка последней версии кода, наличие необходимого программного обеспечения и т. Д. У разработчика нет шансов иметь на своем компьютере какие-то случайные библиотеки DLL, которые могут привести к тому, что сборка пройдет или, по-видимому, выйдет из строя случайно.
Ваш сервер сборки может реплицировать целевую среду (операционную систему и т. Д.), И вероятность того, что что-то сработает на рабочих столах разработчиков и перестанет работать, будет меньше.
-
Хотя разработчикам рекомендуется проверять все, что они регистрируют, иногда они просто этого не делают. Тогда хорошо иметь сервер сборки, чтобы ловить тестовые ошибки и сообщать команде, что продукт не работает.
-
Централизованные сборки обеспечивают легкий доступ к метрикам кода - какие тесты пройдены, какие не пройдены, как часто, насколько хорошо ваш код покрыт вашими тестами и т. Д. Наличие четкого понимания состояния качества кодовой базы снижает затраты на обслуживание и тестирование за счет своевременной обратной связи, позволяющей быстро и легко исправлять ошибки.
-
Развертывание продукта упрощено - разработчик или QA не должны помнить несколько шагов вручную. Это может быть легко автоматизировано.
-
Связь между разработчиками и QA упрощена. Сотрудники отдела контроля качества могут отправиться в известное место, чтобы получить последние версии с правильной версией.
-
Легко настроить сборки для веток релиза, предоставляя дополнительную сеть безопасности для продуктов на стадии их выпуска, когда изменения кода должны выполняться с особой осторожностью.
Чтобы избежать проблемы «но это работает на моей коробке».
Имейте согласованную, известную среду, где программное обеспечение построено, чтобы избежать зависимостей от локальных блоков разработки.
Вы можете использовать виртуальный сервер, чтобы избежать (очень) дополнительных затрат, если вам нужно.
Как можно быстрее узнайте, какие модульные тесты работают в настоящее время, а какие нет; более того, вы также узнаете, что один раз пройденные юнит-тесты начнут давать сбой.
Здесь следует подвести итог, почему так важно иметь сервер сборки:
http://www.codinghorror.com/blog/2006/10/the-build-server-your- проекты-сердце-monitor.html
Это приборная панель для непрерывного тестирования качества; он показывает вам статистику о качестве вашего программного обеспечения и показывает вам его сейчас. (JUnit, Cobertura)
Это позволяет разработчикам не мешать другим разработчикам, нарушающим сборку, и призывает разработчиков писать более качественный код. (FindBugs, PMD)
Это экономит ваше время и деньги в течение всего года благодаря первому получению лучшего кода от разработчиков - меньшим затратам на тестирование и повторное тестирование - и получению большего количества кода от тех же разработчиков, потому что они « с меньшей вероятностью сбить друг друга с толку.
Две основные причины, по которым нетехнические люди могут относиться к:
-
Это повышает производительность команды разработчиков, потому что проблемы были определены ранее.
-
Это делает состояние проекта очень очевидным. Я показал своему руководству панель мониторинга состояния сборки, и теперь они все время на нее смотрят.
Еще одна вещь. Нечто подобное Hudson очень просто настроить - вы можете просто запустить его где-нибудь в углу на некоторое время, а затем показать позже.
Это мой главный аргумент:
- все официальные релизы должны быть построены в контролируемой среде. Не исключение.
просто потому, что вы никогда не знаете, как разработчики создают свои личные выпуски.
Вам также не нужно говорить о сервере сборки , как в «лезвии, которое стоит руку за ногу». Первым сервером сборки, который я настроил, был настольный компьютер, который был отключен от сети в углу. Он служил нам очень хорошо в течение более 3 лет.
Как только у вас будет ваш сборочный компьютер, вы можете начать добавлять некоторые функции (Хадсон великолепен) и реализовывать все, что упоминали другие авторы.
Как только ваша сборочная машина станет незаменимой для вашей организации (и все увидят ее преимущества), вы сможете попросить новый блестящий нож, если хотите :-)
Самое простое, что вы можете сделать, чтобы убедить своих работодателей иметь сервер сборки, - это сказать им, что они смогут выпускать быстрее и с лучшего качества .
Более быстрые релизы исходят из непосредственных отзывов о качестве сборки. Если кто-то нарушает сборку, он или она может немедленно исправить поврежденную сборку, избегая задержки в графике сборки и выпуска. Без сервера сборки команде придется тратить время на то, чтобы выяснить, что и когда произошло, и как это исправить.
Лучшее качество достигается за счет того, что сервер сборки автоматически запускает инструменты обнаружения ошибок каждый раз, когда кто-то проверяет изменения в системе контроля версий. Вы не упоминаете, что является основным языком разработки в вашей организации, но такие инструменты, продвинутые, но коммерческие и простые, но бесплатные, существуют практически для всех языков. На ум приходят Lint, FxCop, FindBugs и PMD.
Вы также можете проверить эту презентацию о преимуществах непрерывной интеграции для более подробного обсуждения.