自动化部署的一次实践

问题

现有的状态:需要部署最新代码时,手动在Bamboo上trigger build,然后手动到nexus目录下下载tar包,然后手动用Filezila上传到Server对应目录下,解压后运行。

期望达成的状态:需要部署最新代码时,直接在Server上跑一个脚本,然后它会自动下载并解压。

分析

对于存在的问题,将其细化拆分,一一分析解决方案。

问题1:需要每次手动trigger build。
解决1:在Bamboo上设置自动化的build schedule。

问题2:需要手动下载并解压build好的tar包。
解决2:写一个download package的脚本。

至此,上述的问题已经得到解决。

解决

Fix 1: Configure build schedule -> Bamboo

Bamboo -> Action/Configure Branch -> Plan Configuration -> Triggers -> Add trigger

Bamboo上的trigger build strategy(笔者认为)可以分为两大类:一是poll build,去poll repo,有change的话就build。二是fix build,受到trigger后一定会做一个build,不管有没有change。
而这两大类有有各种细分:比如按频率来算,每小时一次。比如按时间来算,早晚8点一次。比如设置一个规则,满足条件的话trigger。具体的可以看这里:Triggering builds - Bamboo Support

总的来说,Bamboo的设置还是比较容易上手的。

Fix 2: Add download script -> shell

shell script可以分为三个部分,第一部分,读取输入参数。这里主要用到了getopts这个命令。

## get input params
while getopts hxp:b: arg; do
case $arg in
    h)
    echo "downloadsnap [-x (extract after download)] [-p <package-name>] [-b <branch>]"
    exit
    ;;
    p)
    package=$OPTARG
    ;;
    x)
    extract=1
    ;;
    b)
    branch=/$OPTARG
    ;;
esac
done

第二部分,实现核心逻辑,即下载。这里主要用到了wget命令。

## search on nexus and download latest snapshots
mkdir snaptemp
rm ./download_info.txt 2> /dev/null
date +%x_%H:%M:%S:%N >>download_info.txt
pkglst=$(wget -r -A package.tarxxx -P snaptemp --no-parent http://path/to/repo/${branch}/path/to/project/     |& grep some_key_word | awk '{print $NF}' | sort -V | awk -F '/' '{ map[$(NF-2)]=$0;} END{for( key in map) print map[key];}' | grep -i "$package")
echo "$pkglst" | while read line; do
    echo $line
    wget -r -A package.tar -P snaptemp --no-parent $line
done

第三部分,后续一些清理工作。这里主要是清理文件(mv,rm),解压缩(tar)。

## move from temp folder to base folder and extract
for f in $(find snaptemp -name \*package.tar); do
    rm ./$(basename $f) &>/dev/null||:
    mv $f $(basename $f)
    if [[ $extract -eq 1 ]]
    then
        tar xvf $(basename $f)
        rm ./$(basename $f) &>/dev/null||:
    fi
done
rm -rf ./snaptemp

注:一些具体的路径名和其它细节已经隐去,不过大体实现的思路和逻辑都描述出来了。写任何的script,大都可以分为以上三块:读取输入,处理,清理环境。

优化

在实现的过程中,又发现一个问题,即所有build好的snapshot文件上传的路径都是一样的。如下在pom.xml中的定义:

<distributionManagement>
    <repository>
        <id>my-releases</id>
        <name>My Releases</name>
        <url>http://path/to/my/releases</url>
    </repository>
    <snapshotRepository>
        <id>my-snapshots</id>
        <name>My Snapshots</name>
        <url>http://path/to/my/snapshots</url>
    </snapshotRepository>
</distributionManagement>

当大家都用的是一个git branch的时候,完全没有问题,但是如果有多个branch同时开发并需要联动Bamboo自动化部署时,就有问题了。

这里的问题是:难以快速区分不同branch代码的build版本。举例,开发A用branch_a build出来的一个包是repo_1.5.5,开发B用branch_b build出来的一个包是repo_1.5.6,两者在同一目录下。
虽然两者的version不一样,但是很难快速区分,需要分别去看自己的build log,然后根据里面打出的version版本来做出判断。但是,以上的自动化方案没有办法做出这种判断。

解决的方案有很多,列举两个:

  • 1.在build好的包中加入一些metadata信息,包含git branch,download script读取metadata,只抓去对应的branch的包。
  • 2.根据路径区分不同branch,比如branch_a的包会上传到/branch_a/repo,以此类推。download script就只需要到对应的路径下抓取。

方案一的pom部分改动如下,主要是用了buildnumber-maven-plugin和maven-jar-plugin,前者生成一些git info,后者将这些信息写入jar。

<!-- generate build timestamp, version, branch related info -->
<plugin>
    <groupId>org.codehaus.mojo</groupId>
    <artifactId>buildnumber-maven-plugin</artifactId>
    <version>1.4</version>
    <executions>
        <execution>
            <id>generate-timestamp</id>
            <phase>validate</phase>
            <goals>
                <goal>create</goal>
            </goals>
            <configuration>
                <format>{0,date,MMM-dd HH:mm:ss z}</format>
                <items>
                    <item>timestamp</item>
                </items>
                <buildNumberPropertyName>buildDateTime</buildNumberPropertyName>
                <getRevisionOnlyOnce>true</getRevisionOnlyOnce>
            </configuration>
        </execution>
        <execution>
            <id>generate-buildnumber</id>
            <phase>validate</phase>
            <goals>
                <goal>create</goal>
            </goals>
            <configuration>
                <revisionOnScmFailure>0</revisionOnScmFailure>
                <useLastCommittedRevision>true</useLastCommittedRevision>
                <buildNumberPropertyName>buildRevision</buildNumberPropertyName>
                <scmBranchPropertyName>buildBranch</scmBranchPropertyName>
            </configuration>
        </execution>
        <execution>
            <id>create-metadata</id>
            <phase>generate-resources</phase>
            <goals>
                <goal>create-metadata</goal>
            </goals>
            <configuration>
                <attach>true</attach>
                <properties>
                    <buildBranch>${buildBranch}</buildBranch>
                </properties>
                <addOutputDirectoryToResources>true</addOutputDirectoryToResources>
            </configuration>
        </execution>
    </executions>
</plugin>

<!-- add git branch info to metadata when building jar -->
<plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-jar-plugin</artifactId>
    <version>3.1.1</version>
    <configuration>
        <archive>
            <index>true</index>
            <manifestEntries>
                <Git-Revision>${buildRevision}</Git-Revision>
                <Build-Time>${buildDateTime}</Build-Time>
                <Git-Branch>${buildBranch}</Git-Branch>
            </manifestEntries>
        </archive>
    </configuration>
</plugin>

方案二的pom部分改动如下:主要是用了maven-deploy-plugin来override snapshot location。

<!-- set up overridden snapshot deploy location -->
<plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-deploy-plugin</artifactId>
    <version>3.0.0-M1</version>
    <configuration>
        <altSnapshotDeploymentRepository>
            my-snapshots::some/path${buildBranch}
        </altSnapshotDeploymentRepository>
    </configuration>
</plugin>

总结

针对开发中的问题,本文从三个层次实现了自动化部署,提高了开发测试的效率。

  • Configure build schedule -> Bamboo
  • Add download script -> shell
  • Change snapshot deploy location -> pom.xml

原文地址:https://www.cnblogs.com/maxstack/p/10654128.html

时间: 2024-08-23 07:11:35

自动化部署的一次实践的相关文章

Cobbler自动化部署最佳实践

第1章 Cobbler自动化部署最佳实践 运维自动化在生产环境中占据着举足轻重的地位,尤其是面对几百台,几千台甚至几万台的服务器时,仅仅是安装操作系统,如果不通过自动化来完成,根本是不可想象的. 面对生产环境中不同服务器的需求,该如何实现批量部署多版本的操作系统呢?Cobbler便可以的满足这一实际需求,实现多版本操作系统批量部署. 笔者QQ:572891887 Linux架构交流群:471443208 1.1 Cobbler简介 Cobbler是一个快速网络安装linux的服务,而且在经过调整

中小企业自动化部署实践

转载:http://www.unixhot.com/article/31 我们今天的话题是中小企业如何实现自动化部署,为什么定位中小企业呢?因为中小企业常面临着运维人员有限,成本投入有限,但是版本更新快,而且服务器数量 却并不少的局面.基本不会投入运维开发来开发自动化部署平台,那么我们今天就拿运维工程师都熟悉的Shell进行举例,谈谈如何来进行一个自动化部署的设计 1.1    统一认识 在开始之前我们需要先统一认识,在IT管理里面有三大核心要素是PPT,也就是人员/组织架构(People).流

Linux LTMP手动编译安装以及全自动化部署实践

前言 现在很多朋友都了解或者已经在使用LNMP架构,一般可以理解为Linux Shell为CentOS/RadHat/Fedora/Debian/Ubuntu/等平台安装LNMP(Nginx/MySQL/PHP),LNMPA(Nginx/MySQL/PHP/Apache),LAMP(Apache/MySQL/PHP)等类似的开发或生产环境.我自己是从SuSE/Oracle商业化环境走出来的,对于开源的部署方案也是在一点一点摸索,我相信其中也必然包含某些坑爹的配置.这篇文章较为详细的描述了基于LT

Django 1.6 最佳实践: django项目的服务器自动化部署(转)

原文:http://www.weiguda.com/blog/41/ 当我们设置服务器时, 不应该每次都使用ssh登录服务器, 再按照记忆一步一步的配置. 因为这样实在是太容易忘记某些步骤了. 服务器设置应当自动化, 并写成文档. 在django用户中, Ansible, SaltStack, Puppet和Chef是最流行的四款自动化部署工具. 这些工具似乎都需要长时间学习才能使用, 因为这些工具不是为一台服务器设置的, 而是针对多台服务器的. 以下是这些工具的基本功能: 远程通过apt-ge

前端自动化部署的深度实践

年前我也在自动化部署这方面下了点功夫,将自己的学习所得在自动化部署的一小步,前端搬砖的一大步这篇博客中做了分享.感谢两位网友@_shanks和@TomCzHen的意见,让我有了继续优化部署流程的动力.本文主要是在自动化部署流程中,对版本管理和流程合理性等方面做了一些改进,配合规范的工作流,使用体验更佳! 更新日志自动生成 之前我都是手动修改CHANGELOG.md,用来记录更新日志,感觉操作起来有点心累,也不是很规范.好在已有前人种树,于是我就考虑利用conventional-changelog

MDT 2013 从入门到精通之自动化部署WinSer 2012 R2

Windows Server 2012 R2 是由Microsoft设计开发的新一代的服务器专属操作系统,其核心版本号为 Windows NT 6.3 .提供企业级数据中心与混合云解决方案,直观且易于部署.具有成本效益.以应用程序为重点.以用户体验为中心,深受广大 IDC 运营商青睐.之前有好多朋友说MDT无法部署全新设计后的2012,本文将简单介绍该服务器操作系统的自动化部署过程.同时建议大家在使用MDT的时候多测试,因为实践是检验真理的唯一标准,我们测试的结果是为了我们更好的部署自动化,可能

持续集成之“自动化部署”

在前文<依赖管理>中,我们讨论了如何在代码变得庞大,组件增多的情况下,做好外部库和内部组件依赖管理,从而提高构建效率.可以应用的实践包括:一次生成,多次复用:建立统一制品库,外部依赖库可以使用像Maven或Ivy这样的工具进行统一管理:对架构进行调整,使一个大的代码库分成多个组件:每个组件有自己的持续集成体系:对多个组件做持续集成.然而,解决一个问题后,总会有另一个问题等在那里,需要你来解决.这次Joe的团队遇到了部署问题. 星期一早上,Alice一进办公室,就看到一脸倦意的Joe坐在椅子上,

cobbler自动化部署指南

文章结构 1. 前言 2. cobbler安装 3. 系统定制 4. 参考链接 前言: 给电脑装过系统的同学都知道,不论是从U盘.光驱或者其他设备装系统,都需要先在BIOS里设置开机启动项(或用开机快捷键设置).从上大学到现在,我帮同学装系统少说也有上百次,但是还从来没有使用从网卡启动安装过,虽然以前也注意到,但一直不知道那是个什么玩意,见图(1).前段时间在实习公司做Openstack的自动化安装与部署工作,才有幸接触到,原来这是一种从网卡远程启动的技术! 图1 BIOS启动项界面 要从网卡启

品尝阿里云容器服务:初步尝试ASP.NET Core Web API站点的Docker自动化部署

部署场景是这样的,我们基于 ASP.NET Core 2.0 Preview 1 开发了一个用于管理缓存的 Web API ,想通过阿里云容器服务基于 Docker 部署为内网服务. 在这篇博文中分享一下经过实践验证的操作步骤: 一.创建与配置集群 1)首先创建一个 Swarm Mode 的集群(注意创建时不要选择“自动创建负载均衡”,因为我们部署的是内网服务,自动创建的是公网负载均衡,需要手动创建内网负载均衡并绑定到集群): 2)集群创建成功后,会在集群列表中显示下面的信息: 3)接着创建一个