.NET FW应用的SW开发生命周期
我们有Legacy .NET FW 3.5应用程序。作为DevOps工程师，我负责此应用程序的CI/CD管道。我有部署的经验不同的应用程序。 SDLC用于Java，JS，Python，Docker，Helm，所有这些对我来说都很清楚，但是我在此.NET世界上需要一些帮助。
我正在关注git流，所以期待这种行为： 开发分支构建：结帐，构建Nuget软件包，将此快照版本部署到二进制存储，将Nuget软件包部署到服务器并运行应用程序 主分支构建：结帐，构建Nuget软件包，将发布版本部署并促进二进制存储，将Nuget部署到服务器到UAT环境。
但是对我来说，Nuget包装似乎更被用于存储库，依赖项等...但是，将应用程序二进制二进制二进制存储中的应用程序用于某种.NET FW后端应用程序的正确方法是什么？
We have legacy .NET FW 3.5 App. Me as a DevOps engineer I'm responsible for CI/CD pipeline for this app. I have experiences with deployment different kind of application. SDLC for Java, JS, Python, Docker, Helm, all of these are pretty clear to me, but I need some help with this .NET world.
I'm following git flow, so expect this behavior:
Develop branch build: checkout, build nuget package, deploy this snapshot version to binary storage, deploy the nuget package to server and run the app
Master branch build: checkout, build nuget package, deploy and promote the release version to binary storage, deploy nuget to server to UAT environment.
But for me it seems nuget packaging is more used for storing libraries, dependencies, etc... But what is the proper way of keeping the application binary in binary storage for some kind of .NET FW backend application for example?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
首先：确保使用.NET Framework 3.5 服务包1 - 否则您将不支持。甚至更好，如果可能的话，升级到较新的版本。但是回到话题。
您是对的，诸如Nuget.org之类的平台旨在用于存储依赖性，而不是应用程序本身。
伪像有点特别，因为有人可以说它是一种通用的人工制品存储 - 既适用于依赖性和应用程序本身。
因此，如果您对文物的nuget提要，则只能将应用程序的依赖项放在那里（也可以从Nuget.org镜像或Company-internal Nuget软件包）。
但是我认为创建专用的文物供稿是完全可以的，您将应用程序二进制文件放置在生产中，因为它们将被消耗/部署。
关于 .net World ：.NET Framework 3.5是如此旧，当时没有常见和广泛采用的方法来存储和版本化应用程序文物 - 至少我不知道。有些使用FTP共享，另一些仅使用生产服务器等。
如今，.NET应用程序（例如MicroService或Web API）作为Docker Image出现，存储在任何Docker注册表中。
First of all: make sure to use .NET Framework 3.5 Service Pack 1 - otherwise you'd be out of support. Or even better, upgrade to a newer version if possible. But back to topic.
You're right, platforms like nuget.org are intended to be used to store dependencies, not the applications itself.
Artifactory is imho a bit special, because one could argue that it is a generic artifact storage - both for dependencies and the application itself.
So if you have a NuGet feed on Artifactory, only the application's dependencies should be placed there (either mirrored from nuget.org or company-internal NuGet packages as well).
But I think it's totally fine to create a dedicated Artifactory feed where you place the application binaries as they'll be consumed/deployed in production.
Regarding the .NET world: .NET Framework 3.5 is so old, no common and widely adopted approach existed back then to store and versionize application artifacts - at least I don't know. Some use an FTP share, others only the production servers, etc.
Nowadays it is most likely that a .NET app (e. g. microservice or web API) comes as a Docker image, stored on whatever Docker registry is appropriate.