Как настроить тестовый сервер, чтобы одновременно можно было тестировать несколько версий проекта?

Question

[MFT]

Я программист, гитом раньше пользовалась только в более простых случаях. Сейчас понадобилось организовать совместную работу небольшой команды разработчиков на удаленном сервере. Разрабатываем web-приложение. Хотелось бы, чтобы у каждого программиста была своя ветка, даже желательно, чтобы для каждой подзадачи были свои ветки. Но сложность в том, что эти ветки нужно еще и тестировать одновременно. То есть, своя версия приложения должна запускаться на этом же сервере разработки для отладки и тестирования (какой будет при этом URL приложения - не важно). Желательно, но не обязательно, каждая ветка должна работать со своей копией БД.
В одном из своих проектов я видела, что так можно организовать работу. Но не знаю, как это сделать. Прошу хотя бы сориентировать, где почитать про это.

Comments

[FanatPHP]

"Тётенька, дайте попить, а то так есть хочется, что аж переночевать негде!"

Как настроить гит для совместной разработки чтобы были тестовые копии для каждой ветки, да ещё и каждая со своей копией базы данных? Вам не кажется, что задача несколько выходит за рамки работы с системой контроля версий ;)

[MFT]

Кажется, но ведь как-то это можно сделать.

[MFT]

Своя копия БД необязательна.

[FanatPHP]

По сути, этот вопрос даже совсем не про гит, а про настройку тестового сервера.
потому что если у нас уже есть ветка проекта, то никто не мешает сделать чекаут этой ветки на тестовом сервере и тестировать.
То есть надо просто сделать тестовый сервер с возможностью на лету создавать виртуальные серверы, просто добавив папку.
ну а дальше там уже можно очень много накрутить - CI, вот это вот всё

[MFT]

Спасибо!

[sswwssww]

MFT, гугли CI/CD, инфы ОЧЕНЬ много. Насчет тестов, в Django, например, при их запуске автоматически создается ПУСТАЯ тестовая БД с полной копией таблиц, связей и т.п. настоящей, в самих тестах создаем нужные данные и тестовые сценарии, а после завершения тестов БД автоматически уничтожается. Думаю для PHP тоже есть что-то подобное. Если нет, то можно самому создать код который перед тестами создает БД, накатывает миграции, а после прогона тестов - уничтожает эту БД.

[MFT]

Спасибо! Под тестами я не имела в виду автоматическое тестирование, не доросли до этого пока. Только вручную проверяем. Но запустить приложение для каждой ветки очень нужно.

[FanatPHP]

MFT, можно задать несколько уточняющих вопросов? Чтоб просто понять контекст (а то без контекста получаются только вот такие словоизвержения типа ответа ниже).
Кто вы этой команде?
Есть ли у вас уже тестовый сервер? Какова его конфигурация (программная)?
Есть ли боевой сервер?
Кто их настраивает (если есть)? Есть ли в команде админ?

[Владимир Коротенко]

Вот вам пример дженкинса
jenkins-development

Правило такое есть 3 ветки prod, stage,dev
в дженкинсе есть 3 задачи каждая вытаскивает соответствующую ветку из гита, дальше откомментирую в коде

// @Library('jenkins-shared-libs') _



pipeline {
	agent any
	environment {
		projectKeyFront = 'kvn-yanotes-front'
		projectKeyBack = 'kvn-yanotes-back'
                // переменные для сборки спа приложения см. vue env files
		VUE_APP_STS_SERVER= 'https://auth.yanotes-dev.loc'
		VUE_APP_REDIRECT_BASE = 'https://yanotes-dev.loc'
		VUE_APP_CLIENT_NAME = 'yanotes_dev'
	}

    stages {

		stage('build client app') {
			agent { 
				dockerfile { 
                                        // контейнер для ноды что бы не мусорить
					filename 'Dockerfile-node'
					//additionalBuildArgs  '--build-arg version=1.0.2'
					//args '-u 1001:1001'
				}
			}
            steps {
                // просто команды для сборки
                sh 'cd ./YANotesServer/App/ && npm install --verbose'
				sh 'cd ./YANotesServer/App/ && npm run build'
				stash includes: 'YANotesServer/App/**/*', name: 'client-app'
				sh 'rm -rf ./YANotesServer/App'
            }
			
        }
		
		stage('build server app') {
			agent { 
				dockerfile { 
                                         // сборка дотнета 
					filename 'Dockerfile-dotnet-microsoft6'
				}
			}
            steps {
				unstash 'client-app'
				
				
					sh '''
						
						dotnet publish --framework net6.0 --configuration Release --runtime centos-x64 ./YANotes.sln
						
					'''
				
				
				stash includes: 'StsServer/bin/Release/net6.0/centos-x64/publish/**/*', name: 'auth'
				stash includes: 'YANotesServer/bin/Release/net6.0/centos-x64/publish/**/*', name: 'app'
            }
        }
                // устанавливаем демоны и перезапускаем их, ssh по ключам должен быть настроен
		stage('install systemd unit file') {
			agent any
			steps {
				sshagent(['jenkins-ci-yanotes-dev']) {
				
					sh 'scp SystemdUnitFiles/yanotes.service-Dev [e-mail]:/etc/systemd/system/yanotes.dev.service'
					sh 'scp SystemdUnitFiles/yanotes.auth.service-Dev [e-mail]:/etc/systemd/system/yanotes.auth.dev.service'
					sh 'ssh -o StrictHostKeyChecking=no [e-mail] systemctl daemon-reload'
					sh 'ssh -o StrictHostKeyChecking=no [e-mail] systemctl enable yanotes.dev'
					sh 'ssh -o StrictHostKeyChecking=no [e-mail] systemctl enable yanotes.auth.dev'
					
				}
			}
		}

		stage('deployment web application') {
			agent any
			steps {
				sshagent(['jenkins-ci-yanotes-dev']) {
					unstash 'app'
					
					sh 'ssh -o StrictHostKeyChecking=no [e-mail] systemctl stop yanotes.dev'
					// sh 'ssh -o StrictHostKeyChecking=no [e-mail] rm -rf /var/yanotes'
					sh 'ssh -o StrictHostKeyChecking=no [e-mail]  mkdir -p /var/yanotes'
					
					sh 'scp -r ./YANotesServer/bin/Release/net6.0/centos-x64/publish/* [e-mail]:/var/yanotes'
					sh 'ssh -o StrictHostKeyChecking=no [e-mail] systemctl start yanotes.dev'
				}
			}
		}

		stage('deployment auth application') {
			agent any
			steps {
				sshagent(['jenkins-ci-yanotes-dev']) {
					unstash 'auth'

					sh 'ssh -o StrictHostKeyChecking=no [e-mail]  systemctl stop yanotes.auth.dev'
					// sh 'ssh -o StrictHostKeyChecking=no [e-mail]  rm -rf /var/yanotesauth'
					sh 'ssh -o StrictHostKeyChecking=no [e-mail] mkdir -p /var/yanotesauth'
					sh 'ssh -o StrictHostKeyChecking=no [e-mail] mkdir -p /var/yanotesauth/logs'
					sh 'ssh -o StrictHostKeyChecking=no [e-mail] chmod 777 /var/yanotesauth/logs'
					
					sh 'scp -r ./StsServer/bin/Release/net6.0/centos-x64/publish/* [e-mail]:/var/yanotesauth'
					sh 'ssh -o StrictHostKeyChecking=no [e-mail]  systemctl start yanotes.auth.dev'
									
				}
			}
		}

    }
}

yanotes.auth.service-Dev

[Unit]
Description=YANotes auth service

[Service]
WorkingDirectory=/var/yanotesauth
SyslogIdentifier=yanotes.auth.dev
ExecStart=/usr/share/dotnet/dotnet /var/yanotesauth/StsServerIdentity.dll --urls="https://localhost:44356"
Restart=always
# Restart service after 10 seconds if dotnet service crashes
RestartSec=10
User=yanotes
Environment=ASPNETCORE_ENVIRONMENT=Development
Environment=DOTNET_PRINT_TELEMETRY_MESSAGE=false

[Install]
WantedBy=multi-user.target

[FanatPHP]

Как всегда, наш Володенька разговаривает с голосами в своей голове :)

[Владимир Коротенко]

FanatPHP, как всегда ты не по делу

[MFT]

Спасибо! Буду разбираться.

[FanatPHP]

MFT, это кусок конфига оркестратора. Для ноды. Вам это бесполезно чуть более, чем полностью.
Плюс тут ветки жёстко заданы, а не как у вас динамически

[Владимир Коротенко]

FanatPHP, это полный конфиг. 2/3 это NET 6 node 1/3
И я в общем то дал как пример, а не говое решение

Answer 1

[Saboteur]

В вашем случае было бы удобнее всего работать с докером.
При этом все тесты должны быть автоматическими и запускаться на localhost

Любым CI инструментом настраиваете триггер на коммит или пулл реквест, чтобы собрать проект, сбилдить докер образ, запустить его и внутри запустить автотесты.

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

Comments

[gram2005]

Да и для ручных тестов подойдёт. Пакуешь сервис в контейнер, отдельным крнтейнером базу данных, отдельным можно какой flyway для миграции. Легче всего связать всё это через docker-compose. Каждый разработчик должен использовать отдельный порт, который будет связан с 80 портом контейнера с сервисом.

[Saboteur]

Каждый разработчик должен использовать отдельный порт

Вот с этим и начинается проблема, потому что у каждого разработчика может быть несколько веток, и манаджить это все руками - геморой.
Зато такое довольно легко манаджится в Kubernetes/Openshift