имеем несколько разработчиков, один тестовый сервер на который заливается код и тестируется, вариант тестирования на локальной машине стоит очень далеко в очереди вариантов,
понятное дело получили ситуацию доступа к одному файлу нескольких разработчиков,
как обычно организовывают с системой контроля версий при условии тестирования на одном сервере? но чтоб это было удобно и в работе
1. DlTA - 15 Августа, 2012 - 17:55:56 - перейти к сообщению
2. Stierus - 15 Августа, 2012 - 18:02:39 - перейти к сообщению
ставят систему контроля версий - svn или git. Можете купить аккаунт github ... или вопрос был не в этом? 
3. DlTA - 16 Августа, 2012 - 00:17:34 - перейти к сообщению
в другом, сам порядок работы,
попытаюсь описать возможную рядовую ситуацию
я правлю файл, делаю коммит, после чего изменения должны коснуться файлов на сервере
в общем то не очень удобно особенно при дебаге, когда баг в какой нить запятой или точке...
может есть описание как и где это выглядит/происходит
(Добавление)
тоест:
1) накодил, сделал комит, отослал на сервер
2)дебажу на сервере, получаю ошибку, исправляю (или думаю что исправляю)) делаю новый комит отправляю на серве
3)благополучно вздыхаю ибо все работает
но явная неудобность в том что пункт 2 приходится повторять N раз, каждый раз делать комент что и почему, и т.д.
имхо это жесть как не удобно, ибо мне иной раз надоедает, после каждого изменения для проверки кидать изменения на сервер, а тут еще и описывать.
в общем выглядит громоздко, неудобно, долго.
как это дело реализуется обычно?
попытаюсь описать возможную рядовую ситуацию
я правлю файл, делаю коммит, после чего изменения должны коснуться файлов на сервере
в общем то не очень удобно особенно при дебаге, когда баг в какой нить запятой или точке...
может есть описание как и где это выглядит/происходит
(Добавление)
тоест:
1) накодил, сделал комит, отослал на сервер
2)дебажу на сервере, получаю ошибку, исправляю (или думаю что исправляю)) делаю новый комит отправляю на серве
3)благополучно вздыхаю ибо все работает
но явная неудобность в том что пункт 2 приходится повторять N раз, каждый раз делать комент что и почему, и т.д.
имхо это жесть как не удобно, ибо мне иной раз надоедает, после каждого изменения для проверки кидать изменения на сервер, а тут еще и описывать.
в общем выглядит громоздко, неудобно, долго.
как это дело реализуется обычно?
4. DlTA - 21 Августа, 2012 - 10:26:42 - перейти к сообщению
up
5. EuGen - 21 Августа, 2012 - 11:05:36 - перейти к сообщению
Классически каждый разработчик должен иметь у себя локально если не копию проекта (ведь там может быть продуктовая БД, данные которой в ряде случаев обычному разработчику и не должны быть доступны), то его структуру.
В этом случае все мелкие проблемы вроде точки с запятой решаются наличием IDE, более крупные - отладкой на локальной машине.
Затем, следующий этап - это стейджинг-серверы. Изначально разработчик делает коммиты в свою ветку (для того же git к примеру), которую переносит на стейджинг, который является уже точной копией продуктового сервера по части инфраструктуры и платформы, но может не содержать, например, данных БД. Эта ветка предназначена для теста именно той функциональности, которую делает разработчик. Если все происходит успешно, то готовая функциональность попадает в ветку beta-теста (или alpha - зависит от регламента) и передается на проверку QA-отделу вместе с набором входных-выходных данных.
Если функциональность успешно проходит проверку в QA, то она попадает уже в мейнстрим (trunk или master ветки в зависимости от СКВ).
Такая многоступенчатая схема подходит для средних и крупных проектов, на которых заняты команды разработчиков, тестировщиков, верстальщиков, дизайнеров и т.п., для более мелких проектов достаточно иметь, к примеру, один тестовый сервер и одну ветку "тест" для всех новых функциональностей.
Описанная схема относится к так называемой Waterfall-методике организации разработки. Существует альтернатива ей - Agile схемы (с примером реализации в виде SCRUM).
В этом случае все мелкие проблемы вроде точки с запятой решаются наличием IDE, более крупные - отладкой на локальной машине.
Затем, следующий этап - это стейджинг-серверы. Изначально разработчик делает коммиты в свою ветку (для того же git к примеру), которую переносит на стейджинг, который является уже точной копией продуктового сервера по части инфраструктуры и платформы, но может не содержать, например, данных БД. Эта ветка предназначена для теста именно той функциональности, которую делает разработчик. Если все происходит успешно, то готовая функциональность попадает в ветку beta-теста (или alpha - зависит от регламента) и передается на проверку QA-отделу вместе с набором входных-выходных данных.
Если функциональность успешно проходит проверку в QA, то она попадает уже в мейнстрим (trunk или master ветки в зависимости от СКВ).
Такая многоступенчатая схема подходит для средних и крупных проектов, на которых заняты команды разработчиков, тестировщиков, верстальщиков, дизайнеров и т.п., для более мелких проектов достаточно иметь, к примеру, один тестовый сервер и одну ветку "тест" для всех новых функциональностей.
Описанная схема относится к так называемой Waterfall-методике организации разработки. Существует альтернатива ей - Agile схемы (с примером реализации в виде SCRUM).
6. Stierus - 21 Августа, 2012 - 11:28:47 - перейти к сообщению
7. DlTA - 21 Августа, 2012 - 13:10:40 - перейти к сообщению
EuGen пишет:
Классически каждый разработчик должен иметь у себя
...
Существует альтернатива ей - Agile схемы (с примером реализации в виде SCRUM).
...
Существует альтернатива ей - Agile схемы (с примером реализации в виде SCRUM).
пасибки, это примерно так как я и предполагал. хотя надежда тлелась, что может быть что то еще.
8. caballero - 21 Августа, 2012 - 13:17:31 - перейти к сообщению
Цитата:
пасибки, это примерно так как я и предполагал. хотя надежда тлелась, что может быть что то еще.
что то еще - это как у не криворуких разработчиков - сначала исправляется баг потом кладется в системму версионирования а не наоборот. Затем тестер берет оттуда версию и проводит тестирование если все нормально выкладывется на рабочий север