关于持续集成CI踩坑（二）

目标：为一个Django项目添加gitlab CI Runner 中间出的的问题以及别人的回答

一：问题：CI 究竟做了什么？

go语言为例，go语言是一个需要进行编译的语言，只有编译之后，程序才能运行，对吧？

编译这个过程，如果在云端进行，那么这个过程就很像是CI了

编译好的bin（二进制）文件，是在构建服务器上的。把这个bin文件发布到正式服务器，这个过程，就是CD了
当然，CI没有这么简单。CI过程中往往还包含测试、检查代码规范等等步骤。编译只是其中的一个环节
如果用了docker，那么构建好的程序，往往是一个容器

二：问题：CI需要构建一个对立的环境吗？

进行构建的时候，不是将所有依赖直接安装到构建服务器上，而是创建一个相对独立的环境，在这个环境中执行程序。对于go而言，docker；对于python而言，virtualenv；这个相对独立的话环境可以有多个。

这个相对独立的话环境可以有多个：一个OS可以多个docker image；可以有多个 virtualenv；

一般而言，每次构建都会创造一个新的独立环境。

三：问题：创建的独立的环境在哪里呢？

在构建服务器上

requirements.txt 或 Dockerfile 的作用是，保证环境能够被完整的复制和构建；

这已经是devops的范畴了

例如gitlab 的CI Runner 就在安装了Runner并且注册了Runner的服务器上

四：问题：但是构建服务器上我是安装了虚拟环境 但是我运行脚本找不到这个命令可能是有哪种情况呢？

你之所以问这个问题，是因为你bash相关的知识不够完整。建议自己补充一下。

此外，workon这种用法，是virtualenv-wrapper里面的，不是标准的用法；可以用 source venv/bin/activate 这种形式激活python virtualenv 环境。

workon 这个程序（或脚本）在哪里？为什么能够执行？为什么不能够执行？
[https://www.cnblogs.com/Gaoqiking/p/10528509.html](https://www.cnblogs.com/Gaoqiking/p/10528509.html)