Что такое лучшие практики управления исходным кодом и управления конфигурацией?
Преобразование кадра данных в именованный список перед преобразованием в JSON:
library(jsonlite)
tableData <- rbind(col1, col2, col3)
#make a list and then name the elements.
tableData<-list(tableData)
names(tableData)<-"PercentileFromR"
exportJSON <- toJSON(tableData, pretty = TRUE)
exportJSON
# {
# "PercentileFromR": [
# ["499 to 516", "517 to 534", "535 to 552", "553 to 569", "570 to 586", "587 to 604", "605 to 622"],
# ["0", "7", "38", "124", "271", "388", "442"],
# ["4", "6", "35", "68", "81", "71", "33"]
# ]
# }
8 ответов
Для меня правило № 1 таково:
Основное ветвь является священной - она всегда должна быть компилируемой, способной передавать BVT и быть в основном пригодной для использования.
Любой код, которому разрешено переходить в основную ветвь, которая вызывает сборку или разрыв BVT, выявляет ошибку в процессе. Этот процесс должен позволять собирать / тестировать собеседников для систем с одной ветвью или требовать, чтобы дочерние ветви собирали и передавали BVT перед объединением с основной ветвью или другими такими мерами защиты.
Это сильно зависит от того, в какой среде вы строите?
- Это C / MakeFile?
- Это Java / JUnit / Ant?
- Это .NET / NUnit / NAnt?
- Это .NET / MSUnit / MSBuild?
- Это Ruby ...
- Это Python ...
- Является ли это PHP
Каждый из них отличается по подходу и настройке. Поэтому нам нужно знать ваши настройки, прежде чем вам помогут.
My number one item:
- Update often, commit often,
or, as Jeff puts is: Check In Early, Check In Often.
Система должна собрать сама, протестировать и загрузить + build зависимости сами по себе. У меня есть загрузка, сборка и развертывание файла makefile, который «сертифицирован» для моей внешней версии. Этот make-файл также фиксируется в репозитории.
Не забудьте зафиксировать другую, очень важную и в основном пропущенную вещь (входит в комплект из трех):
- Код SQL, который создает макет вашей базы данных (поместите версию в это!).
- Код SQL, который вызывает версию макета вашей базы данных (для обновления)
- Код SQL, который сбрасывает версию макета вашей базы данных (для понижения)
Если вы пройдете эти вопросы из «Теста Джоэля», вам следует на правильном пути:
Вы используете контроль источников?
Вы делаете ежедневные сборки?
У вас есть база данных ошибок?
Исправляете ли вы ошибки перед написанием нового кода?
Мой номер 1: вы можете сделать сборку за один шаг?
Будучи менеджером SCM, лучший ответ, который я могу дать вам на этот вопрос, - «это зависит». Ваш список и порядок значимости элементов в списке будут зависеть от требований вашего проекта, языка, который вы используете, и уровня разработчика.
Одна вещь, которую вы можете считать для меня важной (или # 1) в ЛЮБОМ списке, который вы в совокупности это означает, что ствол или основная ветвь вашего инструмента ОЧЕНЬ жестко контролируются, и только очень немногие из них имеют доступ к импорту или фиксации изменений в нем. Это сэкономит массу головных болей во время выпуска.
Элементы, которые могут быть в любом списке, который вы составляете, это:
- Когда регистрироваться (ежедневно, еженедельно, чаще, реже)
- Когда строит сделано (ежедневно, еженедельно и т. д.
Весь процесс «получения последних» и «строительства» должен быть плавным, легким, быстрым и надежным.
Если нет - разработчики, как правило, пропускают получение последних версий и продолжают работать над устаревшими копиями, и это то, чего вы хотите избежать.
Это более или менее то, что сказал Майкл, - но я хочу подчеркнуть, что за пределами отрасли быть священным и стабильным - весь процесс должен быть быстрым и простым
Вроде как философия Google, согласно которой загрузка \ установка должна быть быстрой и простой