最近一直跟几个小伙伴在讨论敏捷项目及其在具体团队中演进的许多问题。我想敏捷是一个从技术到项目管理等多个层次的立体问题。理念上的东西需要反复地思想碰撞和实践，进而去总结。而技术层面则却可以陆续扩展，对于二三线城市，特别是一些小团队，技术能力和使用工具都有脱离当下发展的情况，其原因并非是团队人员惰怠，而是没有良好的入门引导。所以我在自己的博客中开设“实用小帖”一栏，目的是辅助大家寻找并入门一些好的技术工具。当然，任何技术都可能会过时，这也是我的博客中很少讲解技术代码的原因。不过“实用小帖”旨在抛砖引玉，希望通过更为广泛的交流来让敏捷落地在中小开发团队中。毕竟，在小一点的团队，往往技术负责人是既当“爹”(PM)又当“妈”(Coder)，却为不易。
0. 准备工作
Gitlab在部署的时候会占用三个端口80,443和22，分别是web访问和ssh协议。所以在部署的时候就要把服务器上的这三个端口让出来，当然也可以通过修改配置文件将三个端口修改为其他端口。不过不建议修改22端口，因为一旦修改该端口，所有项目开发人员就需要本地配置git，虽然简单，但由于开发人员可能对git使用能力参差不齐而产生不必要的麻烦，所以并不建议修改22端口。
但是Linux系统往往自带ssh server, 所以需要修改它的默认端口，既
vim /etc/ssh/sshd_config
修改端口号
如此，以后再使用ssh连接服务器的时候，就需要使用命令：
ssh -p <port_number> <username>@<server_ip>
下一步，安装docker。对于小团队的各种管理事务，代码管理，仓库管理，持续集成，数据库管理，数据迁移备份以及部署实施docker绝对是一站式解决方案。
1. docker安装Gitlab
其实很多开发常用的代码管理工具只有svn和git，但实际上还有很多其他产品，不过目前功能和文档最为完善估计只有gitlab了。使用docker安装Gitlab十分方便，首先下载镜像
docker pull gitlab/gitlab-ce:latest
gitlab-ce是社区免费版本，gitlab-ee是企业收费版本，在功能上也有所区别。
接下来创建并运行一个Gitlab容器(注意配置docker的用户组, 避免使用sudo命令)
sudo docker run --detach \
--hostname <server_ip_or_address> \
--env GITLAB_OMNIBUS_CONFIG="external_url 'http://<server_ip_or_address>/' " \
--publish 443:443 --publish 80:80 --publish 22:22 \
--name gitlab \
--restart always \
--volume /data/gitlab/config:/etc/gitlab \
--volume /data/gitlab/logs:/var/log/gitlab \
--volume /data/gitlab/data:/var/opt/gitlab \
gitlab/gitlab-ce:latest
参数说明：
--detach 保持容器后台持续运行
--hostname 设置gitlab的hostname
--env 当中的external_url保证仓库克隆连接的hostname显示正确
--publish 主机与容器的端口映射
--name 设置容器名称
--restart always 设置容器与docker service同步启动
--volume 将主机磁盘挂载到容器，这个很重要，因为即使以后移除该容器，我们同样可以将这些数据挂载到其他容器上
2. Gitlab同步原代码仓库
完成上述过程，配置gitlab的root账号以及注册开发人员账号之后，即可以同步代码仓库，这里很简单。
最后点Create就可以了
*3. 设置镜像仓库
有时候，这种备份是临时解决问题，所以需要更为稳固的仓库进行镜像同步，设置镜像的办法也很简单
这里注意，Gitlab的CE版只能做Push镜像，而EE则支持Push和Pull镜像两种，所以依据仔细需求选择，当然也有其他工具能够解决CE的Pull镜像问题，不过相对比较累赘。实际上多采用ruby脚本写的runner来达到效果。
在输入镜像仓库地址时，可以把镜像仓库的用户名写入url，格式为
http://<username>@<mirror_repo_address>/
这里，如果只同步保护分支的话，那么是每分钟同步一次。
而如果同步所有分支的话，那么就是每五分钟同步一次。
*4. 关于Docker使用的扩展
在团队业务线累积的过程中，往往会诞生一些工具，基于maven或graddle等现在的项目管理工具，这些工具也可能作为常用框架在公司内部累积起来，此时这些项目的维护共享等事务就成了比较重要的事儿，如果每次需要开发人员自行打包编译，比较麻烦，而且往往因为技术能力和环境问题出现各种问题。所以我个人喜欢利用Docker在公司内部放置Maven，NPM，Python，.net core等一些私有仓库，这样当这些框架累积起来时，我只需要在项目的配置文件中指定，那么所有开发人员的内部框架使用就会立即同步，十分方便。
