什么是gitlab“环境”与软件运行环境相比？
根据其文档，GitLab环境由名称组成，并由URL组成。在我的软件职业中，“环境”有一个名称，例如“生产”，但由操作系统，安装依赖项，位置，磁盘容量，数据库连接等组成。
我已经研究了 gitlab docs 和 stackoverflow问题 stackoverflow问题 我看到的最接近的是，您可能有一个指向您的代码运行的URL。 Gitlab如何使用可选的URL知道如何仅给定源和名称“ staging”安装我的软件？我正在尝试在托管的GitLab实例的大学中使用网络上的服务器进行连续集成和部署。谁能告诉我我缺少什么概念？
编辑：
示例：我已经在云中构建并安装了一个托管基于Web的调查的生产应用程序。它具有功能代码来提出问题和流程答案，该问题连接到存储调查本身配置的数据库。我已经建立了一个调查管理桌面应用程序，该应用程序允许以本地文件格式创建和编辑调查内容。该应用程序包括一个“部署”按钮，该按钮连接到生产数据库并插入/更新调查细节。我必须在某个时候输入连接字符串，以便我的部署知道要部署的位置，并且我必须对SQL命令和其他逻辑进行编程以进行此类部署。较少频率，我更新Web调查应用程序的功能代码。这是一个不同的过程，在该过程中，我远程连接到服务器VM，然后手动将文件放在其位置。
我的问题是关于Gitlab，而不是第三方替代方案和附加组件。
GitLab的环境和部署（或其他DevOps）是否与此类常见情况有关？
如果是这样，我在GitLab中在哪里指定有关如何访问环境和执行部署的无数详细信息（或开球脚本）？
胶在哪里？
GitLab Environments consist of a name and optionally a URL, according to its docs. In my software career an "environment" HAS a name, like "production", but CONSISTS of things like operating system, installed dependencies, location, disk capacity, database connections, etc.
I have looked at GitLab docs and
StackOverflow question and
StackOverflow question
and the closest I see is that you might have a URL that points to where your code will run. How does GitLab know how to install my software given only source and the name "staging", with an optional URL? I'm trying to get into continuous integration and deployment, using servers on my network, at a university with its hosted GitLab instance. Can anyone tell me what concepts I am missing?
EDIT:
Example: I have built and installed in the cloud a production application that hosts web-based surveys. It has functional code to present questions and process answers, which connects to a database that stores the configuration of the surveys themselves. I have built a survey management desktop app that allows creation and editing of survey content in a local file format. This app includes a "Deploy" button which connects to the production database and inserts/updates the survey specifics. I had to type in the connection string at some point, for my deployer to know where to deploy, and I had to program the SQL commands and other logic to carry out such a deployment. Less frequently, I update the functional code of the web survey app. That is a different process, in which I connect to the server vm remotely, and manually put the files where they go.
My question is about GitLab, not 3rd party alternatives and add-ons.
Do GitLab's Environments and Deployments (or other DevOps) features pertain to common situations like this?
If so, where in GitLab do I specify the myriad details (or kickoff script) about how to access the environment and execute deployments?
Where is the glue?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
在GitLab中，环境是纯粹的逻辑结构。您可以将CI/CD作业指定为各种环境的部署作业。当您从Gitlab UI中“停止”环境时，您还可以指定要触发的作业，但是您需要实现详细信息。 GitLab还提供了“回滚”功能，这实际上只是意味着重新运行较旧的部署作业。
Gitlab存储一些信息并提供了一些胶水，但是它与您实际管理环境内容的方式完全不同，这些环境的内容必须在工作和其他地方实施。
也就是说：Gitlab 不知道在哪里安装软件。您必须实施。 Gitlab的AutodeVops确实提供了一些轻松实施部署的方法，尤其是对于GitLab管理的Kubernetes群集，但最终您可以控制工作的工作以及如何运行环境。您可能会做使用Ansible Playbooks从Gitlab CI 进行管理基础架构
，以进行进一步阅读，请查看Gitlab的博客：如何使用gitlab ci部署到多个环境。
In GitLab, the Environment is a purely logical construct. You can designate CI/CD jobs as deployment jobs to various environments. You can also designate jobs to be triggered when you "stop" an environment from the GitLab UI, but you need to implement the details. GitLab also provides a "rollback" feature, which really just means to re-run an older deployment job.
GitLab stores some information and provides a little glue, but it is entirely separate from how you actually manage the contents of your environment, which you must implement in your jobs and elsewhere.
That is to say: GitLab doesn't know where to install your software. You have to implement that. GitLab's autodevops does provide some ways to easily implement deployments, especially for gitlab-managed Kubernetes clusters, but ultimately you control what your jobs do and how your environment is run. You might do something like use ansible playbooks to manage infrastructure from GitLab CI
For further reading, check out GitLab's blog: How to use GitLab CI to deploy to multiple environments.
虽然“它与您实际管理环境的内容完全分开”，但 sytech 在他的答案中， gitlab 17.6 （2024年11月）确实提出了：
和：
请参阅 gitlab 17.8 （2025年1月）
因此，如果您有部署批准流程，则环境的“部署详细信息”页面现在浮出实际发行说明。不再猜测什么正在发生变化。
您可以在GitLab中打开“发布”页面，并查看所有部署。您还可以将特定的更改，提交或说明链接到环境部署。 FF您有多个人审查或手动批准最终的生产推动力，这应该有所帮助。
While "it is entirely separate from how you actually manage the contents of your environment", as sytech in his answer, GitLab 17.6 (November 2024) does propose:
And:
See GitLab 17.8 (January 2025)
So if you have a deployment approval process, the environment's "deployment details" page now surfaces the actual release notes. No more guesswork about what is changing.
You can open the "release" page in GitLab and see all deployments. You can also link specific changes, commits, or instructions to the environment deployment. Ff you have multiple people reviewing or manually approving a final production push, that should help.
马洛利。胶称为“ .gitlab-ci.yml”。解释被埋葬在这里：
https://docs.gitlab.com/eee/ee/ee/ee/ci/ci/yaml/yaml/gitlab_ci_yamaml，c.gitlab.com/eeme =“ html
“要使用gitlab ci/cd，您需要：
应用程序代码托管在Git存储库中。
文件，其中包含CI/CD配置。
一个名为.gitlab-ci.yml的 文档说您可以使用UI或.gitlab-ci.yml文件来定义环境和部署。您必须在其他地方搜索所有非常重要的.yml文件的语法和选项。
Holy maloley. The glue is called ".gitlab-ci.yml". Explanation is buried here:
https://docs.gitlab.com/ee/ci/yaml/gitlab_ci_yaml.html
"To use GitLab CI/CD, you need:
Application code hosted in a Git repository.
A file called .gitlab-ci.yml in the root of your repository, which contains the CI/CD configuration."
I don't know why this vital foundation isn't positioned more prominently in the docs. Documentation says you can use the UI, or the .gitlab-ci.yml file to define environments and deployments. I mistakenly assumed that meant some kind of equivalence, rather than that the UI provides only the ability to define a stub, and that you have to search elsewhere for the syntax and options for the all-important .yml file.