Владислав Лысков, я разработчки-разработчик и админ-разработчик. Ну собственно вопрос на самом деле в том и есть, что до полноценного скрама недотягивает, но как этих кошек правильно готовить непонятно, не хотелось бы пройтись по всем граблям если существую готовые рецепты на такой случай. Неорганизованно метаться хватаясь за всё что каждому нравится или не нравится - вот чего хотелось бы избежать. Порядка больше хочется. Скрам вроде для этого ок
Sha644, JS? а если PHP то всё? это так не работает? ))) проект на C будет/есть. Вот только как язык разработки с этим связан вообще не понимаю. Доводы разряда - у вас родинка на левой пятке, значит вы умрёте в 45! точка!... Чего так пукан рвёт уважаемый?
Владислав Лысков, ок, но идея в целом хороша, с этим не будет споров? цикличная разработка, бэклог и прочее... порядок и последовательность, именно этого хотелось бы добиться. может есть какие то альтернативные сценарии?
Владислав Лысков, я вот про это и спрашиваю. Хотим пет проект пилить, но в команде пока нас двое всего. Хочу применить SCRUM, ибо он позитивен, но вот что делать с ролями? По сути их всего 3 - Владелец продукта, скрам-мастер, член команды.... но вся идея владельца продукта что он должен знать ЧТО не может влиять на то КАК делать... проблема)
Честно говоря не сталкивался ранее. Хм, почитал немного на вики и честно говоря это может оказаться тем что надо. Вместо того чтобы версионировать всё, заниматься виртуализацие запрашиваемых ПО ресурсов как то реестр, драйвера итд.... может быть то что нужно... Почитаю подробней, посмотрю будет ли работать на XP. К сожалению очень много диллерского софта завязано на этой ОС. Большое спасибо за наводку.
проблема! она в том что переключение между ветками достаточно увесистое и по времени и по объёму дискового пространства. Последнее не критично, так как на том томе куда всё вкатывается посчитали прикинули и с небольшим запасом дали 200Гб. с учётом того что там пермонентно будет только ОС и единственный инстанс софта, будет хватать с избытком на любую конфигурацию. Время переключения между ветками, вот камень предкновения! Именно этот момент плохо удовлетворяет потребности.
Karmashkin: конфликты - нет. тут вся соль что каждая ветка - есть исключительно конкретный набор софта. Ветки между собой не мержаться, ибо в этом вся и суть, изолировать. Версионирование? Скорее всего, да. Выходят обновления для конкретного софта и их конечно накатывать в рамках той ветки необходимо. Но тоже не совсем так, но в целом -одна ось, одна машинка, но софт не дружит между собой, некоторый просто отказывается устанавлиаться пока "вражеский" с его точки зрения не поставишь, другой сносит нужные версии специфических библиотек и ставит свои, после чего "вражесксий" ясное дело больше не взлетает. До определённого предела подходит вариант на разных хардах относительно совместимый софт пользовать. Но чем чище хочется сделать сборку тем больше растёт количество хардов... тоже вроде не комильфо. Хочется найти достаточно гибкое решение, чтобы и оверхэд по железу/дисковой ёмкости держать в разумных пределах.
Алексей POS_troi: про виртуальные машины я немного раскрыл тему в ответах для aol-nnov. Тоже вариант но в некоторых местах есть довольно серьёные трудности с поддержкой железа, а оно специфическое (диагностика/чиптюнинг автомобилей)
вобщем то вопрос был про то как оптимизировать git под эту задачу.... ну да не суть, видимо рунет долго будет не толерантен к вопросам, и ответы будут вместо "попробуй так и так", примерно "чтобы ты не спросил, нафига оно тебе надо и вообще ты дурак" ))) я вообще ждал подобной реакции, но перед тем как идти на буржуйский стэк решил таки хоть и безнадёжно но попробовать.... увы и ах
необходимо около 20+ взаимно практически не совместимых наборов ПО! Придумал, что придумал. Результат на данный момент плохо удовлетворяет потребности. Виртуальные машини вообще первое о чём подумал, даже не смотря на конский оверхэд по использованию диского пространства, даже с учётом что некоторые дистрибутивы могут больше 50Гб занимать. плюс сюда необходимо учесть что будет использоваться в связке со специфическим железом, и не всё из этого нормально переживает проброс в гостевую ОС. Так что да... кой какие мысли уже были на эту тему, и бОльшее предпочтение всётаки именно к реально аппаратной реализации. Так что 100500 виртуалок конечно панацея... но не от всего. Ну и не нужно говорить что накладные расходы по использованию ресурсов компьютера на котором это всё будет запускаться не самые малые... вобщем как то так... думал я про виртуалки... железо на котором это всё планируется использовать довольно бюджетное к тому же.
какие варианты версионирования файлов ОС тогда предложите сударь? с умным видом ляпнуть ничем не аргументированную фразу любой может. Это моё решение, я не утверждал что оно единственно правильное, однако другого на данный момент у меня нет
