JIRA&Bibucket 部署策略

加入到新团队后一直着手于建立统一的标准软件流程,现有的项目因为不同BU的影响,不仅流程各不相同,使用的工具也是五花八门,所以从年初制定KPI时,不仅是制定标准的软件流程,软件开发工具的统一也是一项重要内容。经过各种讨论评估,最终决定使用JIRA和Bitbucket,后续还会有Bamboo和Confluence的加入,最终凑齐Atlasssian全家桶, 完成软件开发从需求管理、任务管理、测试管理、代码管理、缺陷管理、持续集成、文档管理的全流程覆盖。

经过漫长的与sourcing和IT部门的扯皮,终于采购了JIRA和Bitbucket。然后由于IT部门的不作为,所有安装、配置、管理、维护都是自己动手,项目开发的任务之外又承担了配置管理员的角色,虽然这个我这个二把刀管理员搞出来的配置非常不专业,但是因为是自己的心血,还是很有必要记录一下的。

物理架构

  • 考虑到数据安全和扩容的可能性,JIRA和Bitbucket分别部署在不同的服务器上。
  • JIRA和Bitbucket服务器是由公司IT部门提供的虚拟机,提供虚拟机备份,并统一管理计算资源、IP和内部域名。
  • JIRA和Bitbucket邮件通知功能通过SMTP relay转发,主要是因为公司的IT策略不允许架设邮件服务,而且现有SMTP服务只能由特定IP的电脑访问,申请权限给新的IP非常繁琐。所以所有通知邮件使用部门内一台已经有权限的电脑转发。
  • NAS服务器在部门本地部署,主要用来存放JIRA和Bitbucket的数据备份。IT部门已经提供了虚拟机备份,但是由于多次发生虚拟机不能访问和备份丢失的情况,软件团队内部的NAS充当了最后的安全手段。NAS服务器是采购的Synology DS216se双盘位乞丐版,配备两个4T硬盘。
  • NAS服务器并没有使用内部的邮件服务,而是使用微软outlook邮件发送通知。主要是因为当JIRA和Bitbucket服务器发生异常时,通常公司内部的邮件服务器也无法访问,使用外部邮件能确保管理员收到报警通知。

软件架构

Atlasssian服务

  • JIRA和Bitbucket分别架设在两个运行CentOS 7的虚拟机上,虚拟机托管在IT部门的Hyper-V集群上。
  • JIRA和Bitbucket是基于JAVA开发的工具,需要部署在java容器Tomcat之上。作为生产环境,我们还配置了apache服务,做反向代理。JIRA默认使用8080端口,Bitbucket默认使用7990端口,通过apache映射到各自网址的80端口。
  • JIRA和Bitbucket都自带了一个H2 database, 但是在生产环境还是建议使用成熟的数据库,比较JIRA支持的数据库后,最后选定使用PostgreSQL 9.2。
  • JIRA和Bitbucket各自单独运行备份服务,通过FTP上传到NAS服务器。

相关配置方法和文档:

NAS服务

  • Synology NAS 服务器上运行了一个基于网页界面的DiskStation Manager(DSM)操作系统。DSM也是基于Linux,可以提供方便的用户管理、存储管理和计划任务等功能。
  • 只开放了FTP服务,提供给JIRA和Bitbucket一个只有上传权限的用户来备份数据。

相关配置方法和文档:

备份策略

JIRA和Bitbucket备份分两层:

  1. Windows Hyper-V提供的虚拟机备份,每日全盘备份,保留15天。
  2. 保存在NAS服务器上的数据备份,每个工作日备份,保留半年。

JIRA和Bitbucket的数据备份的流程如上图所示:

  • JIRA的备份主要包含两部分:数据库和数据文件夹。这里使用JIRA备份服务和pg_dump两种办法同时备份数据库,除了基于安全性的考虑,还为了照顾不同的恢复策略:pg_dump的备份更方便postgreSQL恢复数据,而JIRA备份服务产生的xml文件可以更方便的恢复到其他不同类型的数据库。
  • Bitbucket提供了三种不同的备份方法。通过对比,根据团队实际情况,选择使用官方提供的“Bitbucket Server Backup Client”,一次就可以将数据库、代码库和相关日志等全部备份。而这种方法在速度和兼容性上的不足,在现在团队规模下,并不会构成问题。
  • 利用DSM系统的“任务计划”功能定时运行自定义服务,定时检查JRIA和Bitbucket服务的是否在线,每日定时检查备份的完整性。

相关配置方法和文档: