共享运行时环境的良好部署和发布策略是什么?

发布于 2024-09-25 05:02:54 字数 666 浏览 9 评论 0原文

现状

对于我们的客户,我们正在开发一些库和应用程序,它们在作为内部 Java Web Start 应用程序交付的较大应用程序中作为“模块”运行。客户维护运行该应用程序的基础设施。 “服务器端”由一些基于Axis2的Web服务组成。这两部分都作为两个单独的 Web 应用程序部署到单个 Tomcat 实例。

当我们发布工件的新版本时,我们只需生成必要的 JAR 文件(例如 ourapp-client.jar 和 ourapp-server.jar)并将它们发送给我们的客户,然后客户将它们放入适当的位置,然后——如果需要--重新启动 Tomcat 服务器。

目标

我们目前正在对所有项目进行 Maven 化,将来我们还希望以“Maven 方式”进行发布。主要目标是使我们这边的发布和部署过程自动化,并使其在客户端更不容易出错,更可靠和舒适。

主要问题

棘手的部分是我们的客户使用相同的 Tomcat Web 应用程序(Axis2 用于“服务器端”和 Web Start 应用程序)将其自行开发的模块包含到应用程序中。因此,我们不能使用显而易见的解决方案,只提供一个简单地部署到服务器中的新 Web 应用程序 (WAR)。这就是为什么我们目前提供“手动”放入正确位置的单个 JAR 文件。

您通常使用哪些策略向客户交付产品?有人有过类似情况的经历吗(即第三方和自行开发的应用程序共享运行时环境)?

Status Quo

For our customer we are developing some libraries and applications that run as "modules" within a larger application that is delivered as a internal Java Web Start application. The customer maintains the infrastructure that this application is run on. The "server side" is made up of a few web services based on Axis2. Both parts are deployed to a single Tomcat instance as two separate web applications.

When we are releasing new versions of our artifacts, we just produce the necessary JAR files (e.g. ourapp-client.jar and ourapp-server.jar) and send them to our customer who in turn just drops them into the appropriate places and--if need be--restarts the Tomcat server.

Goals

We are currently Maven-izing all of our projects and in the future we also want to do our releases in a "Maven way". The main goal is to automate the release and deployment process on our side and make it less error prone and more reliable and comfortable on the client side.

Main problem

The tricky part is that our customer uses the same Tomcat web applications (Axis2 for the "server side" and the Web Start app) to include their self-developed modules into the application. So we cannot use the obvious solution and just deliver a fresh web app (WAR) that simply gets deployed into the server. That is why we are currently delivering single JAR files that are put "by hand" into the right location.

What strategies do you in general use for delivering your products to your customer? Does someone have had any experiences with a similar situation (i.e. shared runtime environment for 3rd party and self developed applications)?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

清音悠歌 2024-10-02 05:02:54

主要目标是在我们这边实现发布和部署过程的自动化,并使其在客户端更不容易出错,并且更加可靠和舒适。

不确定“发布和部署过程”到底是什么意思(在 Maven 语言中,这是关于 SCM 任务自动化和将工件部署到远程存储库)。
如果这是关于部署到生产机器,我个人认为这并不是 Maven 的真正工作(而且我们不使用 Maven 来做这件事)。也许看看专用的解决方案,例如 ControlTierSmartFrog, 木偶厨师等。

您通常使用哪些策略向客户交付产品?有人有过类似情况的经历吗(即第三方和自行开发的应用程序共享运行时环境)?

我们提供我们可以控制的东西。如果客户想要在给定的应用程序中包含他自己的部分,我们将提供所需的子部件,但包装可能是他的责任。

相关问题

The main goal is to automate the release and deployment process on our side and make it less error prone and more reliable and comfortable on the client side.

Not sure what you mean exactly by "release and deployment process" (in the maven lingua, this is about SCM tasks automation and deployment of artifacts to a remote repository).
If this is about deployment to production machines, I personally don't think this is really a job for Maven (and we don't use Maven for this). Maybe have a look at dedicated solutions like ControlTier, SmartFrog, Puppet, Chef, etc.

What strategies do you in general use for delivering your products to your customer? Does someone have had any experiences with a similar situation (i.e. shared runtime environment for 3rd party and self developed applications)?

We deliver the things we can control. If a customer wants to include his own bits in a given application, we would make the required subparts available but the packaging would probably be his responsibility.

Related questions

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文