У меня около 30 веб-сайтов Wordpress, поэтому способ настройки Jenkins таков: у меня есть работа для каждого веб-сайта.Процесс разработки выглядит следующим образом (я не знаю, является ли он оптимальным, но у нас это так):
- Поскольку у нас есть сторонние разработчики, у них есть собственный репозиторий, размещенный в их собственном репозитории.хостинг провайдер.Всякий раз, когда код готов к QA, они фиксируют все свои изменения в нашем репозитории в основной ветке.
- Затем я запускаю задание Jenkins вручную с файлом jenkins, как показано ниже.
- Рабочий процесс должен быть следующим: развертывание в среде разработки, если и только в случае успешного предыдущего развертывания развертывание на этапе.Здесь мы должны остановиться и позволить специалистам по контролю качества проверять веб-сайт на наличие неработающих ссылок, ошибок и т. Д.
- Если все выглядит так, как мы ожидали, и ошибок не обнаружено, то наконец разверните в производственной среде.
ПРИМЕЧАНИЕ : Некоторые люди предлагали мне только постановку и постановку.Причина, по которой у нас нет такой конфигурации, заключается в том, что среда разработки недоступна в сети, а причина в том, что я использую эту среду для тестирования внутренней конфигурации (например, apache conf и т. Д.).
Кроме того, некоторые другие люди предложили создать ветку для каждой среды, что в теории имеет смысл, но я думаю, что это изменит способ, которым наши разработчики по аутсорсингу передают код в хранилище, я имею в виду, что они всегда должны будут фиксироватькод для ветки dev, а затем слияние с веткой stage для развертывания на stage, что, на мой взгляд, не очень хорошо.
Теперь шаги 2-4 выглядят следующим образом: чтобы дать вам пример того, как выглядит этот процесс, у нас будет пример веб-сайта и задания под названием «Bearitos»:
Внутри этой работы под названием "Bearitos" есть проект под названием "Bearitos to any"
, что в основном означает, что внутри этого проекта у меня есть конвейер, сконфигурированный с тремя этапами: dev, staging и prod, которые параметризованы следующими параметрами: DEPLOY_TO: Dev / staging / prod и DEPLOY_DB: Yes / No.Таким образом, в зависимости от того, что выберет пользователь, Jenkins будет развертывать в той конкретной среде, которая, я думаю, даже не нужна, чтобы эти параметры были правильными, поскольку правильный поток развертывания должен быть dev -> staging -> prod, сценария быть не должногде dev или staging будут пропущены, а затем развернуты прямо рядом с производством, поэтому, по моему мнению, это должно быть обновлено лучше
Внутри Jenkinsfile Iопределили три этапа Dev, Staging или Prod, а также параметры, если было выбрано создание БД или нет, ниже приведен пример того, как выглядит мой Jenkinsfile:
// Deployment template for CMS-based websites (Drupal or Wordpress)
//
//
pipeline {
agent any
parameters {
choice choices: ['Dev', 'Staging', 'Production'], description: "Choose which environment to push changes to.", name: "DEPLOY_TO"
booleanParam defaultValue: true, "Choose whether to deploy the database.", name: "DEPLOY_DB"
}
environment {
SITEID = "lb"
NOFLAGS = "0"
DBNAME = "wpress_myproject"
DBSERVER = "dbserver"
DBUSER = "WordpressUser"
DBPASS = "hiddenpassword"
EXCLUDE = "domain_commentmeta,domain_comments" // separate multiple tables with commas
DEPLOY_TO = "${params.DEPLOY_TO}"
DEPLOY_DB = "${params.DEPLOY_DB}"
}
stages {
stage("deploy-db-dev") {
when {
allOf {
environment ignoreCase: true, name: "DEPLOY_TO", value: "dev";
environment ignoreCase: true, name: "DEPLOY_DB", value: "true";
}
}
steps {
// this stage only required until we make our dev the master DB
// copy full dev database from bolwebdev1
// import latest database dump to dev server
script {
FILENM = sh(script: 'ls -t myproject-s-dump* | head -1', returnStdout: true)
}
//Fixing the problem with the collation existing in the sql dump file, refer to: https://stackoverflow.com/questions/42385099/1273-unknown-collation-utf8mb4-unicode-520-ci
//apparently, this is due to a version of mysql issue. Once the problem is fixed from the server side we can then remove the following lines.
sh """sed -i s/utf8mb4_unicode_520_ci/utf8mb4_unicode_ci/g ${FILENM}
# The following line was added because the site is pointing to a staging server which we don't have control over, again, once this is fixed we can delete the following line of code.
sed -i s/myproject.staging.websites.3pth.com/myproject.example.net/g ${FILENM}
mysql -h devserver2 -u ${env.DBUSER} --password='${env.DBPASS}' ${env.DBNAME}_dev < ${WORKSPACE}/${FILENM}
rm -f ${WORKSPACE}/${FILENM}"""
}
}
stage("deploy-dev") {
when {
environment ignoreCase: true, name: "DEPLOY_TO", value: "dev"
}
steps {
// copy files to devserver2
// NOTE: if we move the repo to SVN, we should change httpdocs/ to ${env.SITEID}docs/
sh """sudo chown jenkins:jenkins *
#Replace the wp-config.php file with our domain file with our information.
/bin/cp httpdocs/wp-config-domain.php httpdocs/wp-config.php
# prepare the dev server to receive files by changing the owner
ssh webadmin@devserver2 'sudo chown -R webadmin:webadmin /var/opt/httpd/${env.SITEID}docs/'
# copy files from control server to dev
rsync --exclude=Jenkinsfile -rav -e ssh --delete ${WORKSPACE}/httpdocs/ webadmin@devserver2:/var/opt/httpd/${env.SITEID}docs/
# fix the owner/permissions on the dev server
ssh webadmin@devserver2 'sudo chown -R apache:${env.SITEID}-web /var/opt/httpd/${env.SITEID}docs/ && sudo chmod -R g+w /var/opt/httpd/${env.SITEID}docs/ && sudo find /var/opt/httpd/${env.SITEID}docs/ -type d -exec chmod g+s {} \\;'"""
}
}
stage("deploy-db-staging") {
when {
allOf {
environment ignoreCase: true, name: "DEPLOY_TO", value: "staging";
environment ignoreCase: true, name: "DEPLOY_DB", value: "true";
}
}
steps {
script {
def myexcludes = env.EXCLUDE.split(',').toList()
MYFLAGS = "-Q -K -c -e --default-character-set=utf8 "
if (env.NOFLAGS == "0") {
myexcludes.each {
MYFLAGS = "${MYFLAGS} --ignore-table=${env.DBNAME}_dev.${it}"
}
}
}
// pull a backup of the current dev database (may exclude some tables)
sh """mysqldump -h devserver2 -u ${env.DBUSER} --password='${env.DBPASS}' ${env.DBNAME}_dev ${MYFLAGS} > ${env.DBNAME}_dev.sql
#Searching and replace for the URL to change from the dev sever to the staging server
sed -i s/myproject.example.net/stage-myproject.example.net/g ${env.DBNAME}_dev.sql
# create a backup copy of the current staging database (full backup)
mysqldump -h ${env.DBSERVER} -u ${env.DBUSER} --password='${env.DBPASS}' ${env.DBNAME}_stage > ${env.DBNAME}_stage_bak.sql
# upload the dev database dump to the staging database
mysql -h ${env.DBSERVER} -u ${env.DBUSER} --password='${env.DBPASS}' ${env.DBNAME}_stage < ${WORKSPACE}/${env.DBNAME}_dev.sql
rm -f ${WORKSPACE}/${env.DBNAME}_dev.sql"""
}
}
stage("deploy-staging") {
when {
environment ignoreCase: true, name: "DEPLOY_TO", value: "staging"
}
steps {
// copy files from dev to control server
sh """rsync --exclude=.svn --exclude=.git -rav -e ssh webadmin@devserver2:/var/opt/httpd/${env.SITEID}docs/ /tmp/${env.SITEID}docs/
#Replace the wp-config.php file with our domain file with our information.
/bin/cp httpdocs/wp-config-domain.php httpdocs/wp-config.php
#prepare the staging server to receive files by changing the owner
ssh webadmin@stageserver 'sudo chown -R webadmin:webadmin /var/opt/httpd/${env.SITEID}docs/'
# copy files from control server to staging
rsync --exclude=.svn --exclude=.git -rav -e ssh --delete /tmp/${env.SITEID}docs/ webadmin@stageserver:/var/opt/httpd/${env.SITEID}docs/
# fix the owner/permissions on the staging server
ssh webadmin@stageserver 'sudo chown -R apache:${env.SITEID}-web /var/opt/httpd/${env.SITEID}docs/ && sudo chmod -R g+w /var/opt/httpd/${env.SITEID}docs/ && sudo find /var/opt/httpd/${env.SITEID}docs/ -type d -exec chmod g+s {} \\;'
#delete the temporary files on the control server
rm -Rf /tmp/${env.SITEID}docs/
# clear the Incapsula caches
if [[ \$( curl -sS -X POST \"http://www.example.net/incapcache.php?api_key=asdaswwGR)feasdsdda&site_id=stage&resource_url=stage-myproject.example.net\" | jq -r .debug_info.id_info) != \"incapsula cache cleared successfuly\" ]]; then exit 255; fi"""
}
}
stage("deploy-db-production") {
when {
allOf {
environment ignoreCase: true, name: "DEPLOY_TO", value: "production";
environment ignoreCase: true, name: "DEPLOY_DB", value: "true";
}
}
steps {
script {
def myexcludes = env.EXCLUDE.split(',').toList()
MYFLAGS = "-Q -K -c -e --default-character-set=utf8 "
if (env.NOFLAGS == "0") {
myexcludes.each {
MYFLAGS = "${MYFLAGS} --ignore-table=${env.DBNAME}_stage.${it}"
}
}
}
sh """cd ${WORKSPACE}
# pull a backup of the current staging database (may exclude some tables)
mysqldump -h ${env.DBSERVER} -u ${env.DBUSER} --password='${env.DBPASS}' ${env.DBNAME}_stage ${MYFLAGS} > ${env.DBNAME}_stage.sql
#Searching and replace for the URL to change from the stage sever to the prod server
sed -i s/stage-myproject.example.net/www.myproject.com/g ${env.DBNAME}_stage.sql
# create a backup copy of the current production database (full backup)
mysqldump -h ${env.DBSERVER} -u ${env.DBUSER} --password='${env.DBPASS}' ${env.DBNAME}_prod > ${env.DBNAME}_prod_bak.sql
# upload the staging database dump to the production database
mysql -h ${env.DBSERVER} -u ${env.DBUSER} --password='${env.DBPASS}' ${env.DBNAME}_prod < ${WORKSPACE}/${env.DBNAME}_stage.sql
rm -f ${WORKSPACE}/${env.DBNAME}_stage.sql"""
}
}
stage("deploy-production") {
when {
environment ignoreCase: true, name: "DEPLOY_TO", value: "production"
}
steps {
// copy files from staging to control server
sh """rsync --exclude=.svn --exclude=.git -rav -e ssh webadmin@stageserver:/var/opt/httpd/${env.SITEID}docs/ /tmp/${env.SITEID}docs/
# prepare the production server to receive files by changing the owner
ssh webadmin@prodserver1 'sudo chown -R webadmin:webadmin /var/opt/httpd/${env.SITEID}docs'
ssh webadmin@prodserver2 'sudo chown -R webadmin:webadmin /var/opt/httpd/${env.SITEID}docs'
# copy files from control server to production
rsync --exclude=.svn --exclude=.git -rav -e ssh --delete /tmp/${env.SITEID}docs/ webadmin@prodserver1:/var/opt/httpd/${env.SITEID}docs/
rsync --exclude=.svn --exclude=.git -rav -e ssh --delete /tmp/${env.SITEID}docs/ webadmin@prodserver2:/var/opt/httpd/${env.SITEID}docs/
# fix the owner/permissions on the production server
ssh webadmin@prodserver1 'sudo chown -R apache:${env.SITEID}-web /var/opt/httpd/${env.SITEID}docs/'
ssh webadmin@prodserver2 'sudo chown -R apache:${env.SITEID}-web /var/opt/httpd/${env.SITEID}docs/'
ssh webadmin@prodserver1 'sudo chmod -R g+w /var/opt/httpd/${env.SITEID}docs/'
ssh webadmin@prodserver2 'sudo chmod -R g+w /var/opt/httpd/${env.SITEID}docs/'
ssh webadmin@prodserver1 'sudo find /var/opt/httpd/${env.SITEID}docs/ -type d -exec chmod g+s {} \\;'
ssh webadmin@prodserver2 'sudo find /var/opt/httpd/${env.SITEID}docs/ -type d -exec chmod g+s {} \\;'
# delete the temporary files on the control server
rm -Rf /tmp/${env.SITEID}docs/
# clear the Incapsula caches
if [[ \$( curl -sS -X POST \"http://www.example.net/incapcache.php?api_key=asdaswwGR)feasdsdda&site_id=088&resource_url=www.myproject.com\" | jq -r .debug_info.id_info) != \"incapsula cache cleared successfuly\" ]]; then exit 255; fi"""
}
}
}
}
Проблемы, с которыми я столкнулсяВ настоящее время я сталкиваюсь с таким подходом:
Я не могу понять, как сделать развертывание автоматизированным, поскольку это параметризованный конвейер, поэтому я не уверен, как его автоматизировать.Желательным процессом было бы автоматизировать развертывание после того, как Дженкинс будет опрашивать каждые X минут в репозитории git, автоматически развертывать в Dev> Stage (только если развертывание Dev прошло успешно), а затем останавливаться до тех пор, пока мы не развернем вручную в Prod послеQA on Staging.
В текущей конфигурации Git настроена только одна ветвь (master), в которую разработчики вносят изменения, когда они хотят выполнить развертывание в Dev -> Stage ->Prod.Но я думаю, что идеальный сценарий будет иметь ветку dev для развертываний dev, затем ветвь stage для развертывания в среду Stage и затем master для развертывания, когда мы объединяем эти ветки dev и staging с главной веткой.Я не уверен, что это будет оптимальным, поэтому я был бы признателен за любые предложения или идеи по этому поводу.
Желательным подходом будет разрешение упомянутых проблем, а также возможность автоматического развертывания и уведомления об успешном развертывании dev -> staging. Помимо возможности выполнять упомянутый рабочий процесс вручную, как мы делаем сейчас (это не так важно, но было бы неплохо иметь такую функцию).
Заранее благодарю за помощь!