部署使用 Snap 框架的 Haskell 代码
您在 Snap 中以稳定的方式部署 Haskell 代码进行生产有什么经验？
如果服务器上的编译失败，那么我想中止部署，如果成功，那么我希望它关闭快照服务器并启动新版本。
我知道有很多方法。从 rsync 到 git-hooks 的一切（git pull 是一场噩梦）。但我想听听你的经历。
What's your experience with deploying Haskell code for production in Snap in a stable fashion?
If the compilation fails on the server then I would like to abort the deployment and if it succeeds then I would like it to turn of the snap-server and start the new version instead.
I know there are plenty of ways. Everything from rsync to git-hooks (git pull was a nightmare). But I would like to hear your experiences.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
在我工作的地方，我们使用 Happstack 并部署在 Ubuntu Linux 上。我们实际上对 Web 应用程序和所有依赖项进行 debian，然后在自动构建器中构建它们。
要在服务器上实际安装，我们只需运行 apt-get update && apt-get install webapp-product
该系统的优点是，它使所有开发人员可以轻松地针对同一版本的依赖项进行开发。而且您知道所有源代码都已正确签入，并且可以在任何地方重建......而不仅仅是在一台特定的机器上。此外，它还提供了一种在需要时通过 hackage 对库进行补丁的机制。
缺点是 apt-get 和 cabal-install 不能很好地相处。您要么必须通过 apt-get 构建所有内容，要么通过 cabal-install 完成所有内容。
Where I work, we use Happstack and deploy on Ubuntu linux. We actually debianize the web app and all the dependencies, and then build them in the autobuilder.
To actually install on the server, we just run
apt-get update && apt-get install webapp-productionThe advantage of this system is that it makes it easy for all developers to develop against the same version of the dependencies. And you know that all the source code is checked in properly and can be rebuilt anywhere .. not just on one particular machine. Additionally, it provides a mechanism to make patches to libraries from hackage when needed.
The downside is that apt-get and cabal-install do not get along well. You either have to build everything via apt-get or do everything via cabal-install.
这就是我们所做的。首先，我们的服务器以及我们的开发机器都是相同版本的ubuntu。我们在我们喜欢使用的任何操作系统中编写代码、测试等，当我们准备好推送时，我们会在开发机器上进行构建。只要编译干净，我们就停止（前端服务器数量）/2，rsync 资源目录和二进制文件的新副本，然后使用脚本启动它。然后重复另一半。
在我看来，当您可以轻松地仅传输二进制和静态资产时，我认为您应该质疑在前端服务器上维护完整工具链的逻辑 - 前提是外部库（数据库、图像等）版本与搭建环境。哎呀，只要操作系统和库的版本匹配，您就可以再次使用 virtualbox 实例进行最终编译。
Here's what we do. First off, our servers are all the same version of ubuntu, as well as our development machines. We write code, test, etc. in whatever os we care to use and when we're ready to push we build on the devel machine(s). As long as that compiled cleanly, we stop (number of frontend servers)/2, rsync the
resourcesdirectory and a new copy of the binary, and then use scripts start it back up. Then repeat for the other half.In my opinion, I think you should question the logic of maintaining a full toolchain on your frontend server(s) when you can easily transfer just the binary and static assets - provided that the external libraries (database, image, etc) versions match the build environment. Heck, you could just use a virtualbox instance to do the final compile, again, so long as the release of the os and libraries match.