@kkolorid

Как организовать парную разработку с Git для отладки на сервере?

Исходные данные такие: два разработчика (один из них тимлид) и руководитель проекта. Необходимо организовать разработку и эксплуатацию телеграм-бота на Python (БД: MySQL) с дальнейшей его поддержкой (доработкой) с применением Git на сервере с Linux. Код пишется на личном компе с Windows и PyCharm, а запускаться и тестироваться должен только на сервере (через штатные средства PyCharm, как удаленный проект). Т. е. нужно как-то организовать работу репозиториев так, чтобы на сервере могли функционировать сразу несколько версий бота (наверное): Продакшн, Разработка (общая для проверки руководителем или тимлидом) и по боту на каждого разработчика. Соответственно, у каждой версии свои токены API Telegram.

С Git в командной разработке раньше не работал, хотя примерно представляю как это работает. Поэтому описал требования примерно, как это вижу, в силу своего незнания, могу ошибаться в каких-то моментах, прошу поправить.
  • Вопрос задан
  • 240 просмотров
Пригласить эксперта
Ответы на вопрос 3
@Vitsliputsli
Стандартно, gitflow. К примеру так: разработка ведется в отдельных ветках feature, для интеграции сливаются в dev, на основе dev создается release и после тестирования заливается в master, который и выкладвается в прод.
Разные токены это относится к окружению, в коде этого быть не должно. Окружение собирается сборщиком деплоя, например в Jenkins.
Ответ написан
Комментировать
firedragon
@firedragon
Senior .NET developer
два разработчика (один из них тимлид) и руководитель проекта.

уже несколько смешно, по идее первый должен это знать.
Итак репозиторий создается с 3 ветками

main
stage
dev

каждая фича создается в новой ветке путем клонирования main
шаблон ветки пусть будет vkorotenko/features/42444-fix_css_on_main
где идет имя пользователя, потом что это, потом номер в баг трекере и какое то описание
после выполнения работ идет мердж в dev stage main
для билда используйте дженкинс
вот пример пайплайна

pipeline {
	agent any
	environment {
		projectKeyFront = 'kvn-yanotes-front'
		projectKeyBack = 'kvn-yanotes-back'
		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'
					
				}
			}
            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'
            }
        }

		stage('install systemd unit file') {
			agent any
			steps {
				sshagent(['jenkins-ci-yanotes-dev']) {
				
					sh 'scp SystemdUnitFiles/yanotes.service-Dev root@yanotes-dev.loc:/etc/systemd/system/yanotes.dev.service'
					sh 'scp SystemdUnitFiles/yanotes.auth.service-Dev root@yanotes-dev.loc:/etc/systemd/system/yanotes.auth.dev.service'
					sh 'ssh -o StrictHostKeyChecking=no root@yanotes-dev.loc systemctl daemon-reload'
					sh 'ssh -o StrictHostKeyChecking=no root@yanotes-dev.loc systemctl enable yanotes.dev'
					sh 'ssh -o StrictHostKeyChecking=no root@yanotes-dev.loc systemctl enable yanotes.auth.dev'
					
				}
			}
		}

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

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

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

    }
}
Ответ написан
Комментировать
saboteur_kiev
@saboteur_kiev Куратор тега Git
software engineer
Банально сделать несколько "енвайрнментов", то есть тестовых ботов, и привязать ветки к этим веткам.

Намример можно привязать к именованиям бренчей, и создать заранее токены для release-bot, main-bot, dev1-bot, dev2-bot.
Каждый разработчик делает свои ветки согласно dev1/feature-blabla и так далее.

Триггер на сервере, что если пришел коммит в ветку по указанной регулярке - пересобрать и перезапустить бота с его токенами.
Ответ написан
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы