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备份分两层：

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

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

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