Questions tagged «packages»

3
多存储库环境中的打包和版本策略
我们是一家小型公司，拥有多个团队管理自己的git存储库。这是一个Web平台，每个团队的工件都在一天结束时部署以进行夜间测试。我们正在尝试使围绕版本控制和打包的过程正式化。 每个团队都有一个主分支，负责日常开发。每个团队的质量保证成员都希望将他们团队变更中的工件部署到测试台中，由厨师将所有组件组合在一起。工件是压缩包，但我想将其转换为RPM，以便我们可以正确思考和推理版本。 发布过程涉及从每个git存储库的开发分支（在大多数情况下为master）切断发布分支。然后将其提供给质量保证，由质量保证对一组工件进行测试和签核。 例如，这是一个典型的git存储库及其相关的发行分支： 0-0-0-0-0-0-0-0-0-0 (master) | | 0 0 (rel-1) | 0 (rel-2) 我一直在试图找出一种方案来执行来自开发分支的软件包的版本控制。我们不想过多地标记每个仓库的主分支，并限制标签仅释放分支。但是我们应该能够使用标准的yum / rpm语义查询测试机器中已部署的软件包。当master分支没有标签时，开发版本会是什么样？我知道这git describe可以为我提供构建版本的有用表示，但是当标记分支上的各个发行点时，它可以很好地工作。 编辑1：响应@ Urban48的答案 我认为我应该多解释一下发布过程。为了便于讨论，我们假设master在所有存储库中都有分支。该master分支被视为开发分支，并且已部署到支持CI-CD的自动化QA环境。这是每晚测试的子集，用于确保主服务器的稳定性。在削减发行分支之前，我们先看一下这一系列工作。我们的发行分支是短暂的。假设（从稳定的主服务器上）剪切了一个发布分支之后，将运行完全回归，进行修复并将其部署到生产中。这大约需要一周的时间。我们几乎每两周发布一次产品。 我们的功能分支总是从母版中剪切下来的，并在与母版合并之前经过一定量的开发人员测试，然后对它们进行CI-CD稳定性检查。 修补程序是在修补程序分支（从发行版分支切下的）上进行的，并以最小的影响测试将其部署到生产环境中。 以下是我们针对发行版和修补程序分支的版本控制策略。在质量检查周期中，发行分支会经历的版本v2.0.0-rc1，v2.0.0-rc2最后在质量检查批准后变为v2.0.0。 有时，我们会针对一些小功能进行点发布，这些小功能会合并到版本变为的版本分支（然后合并到母版）中v2.1.0。修补程序采用该v2.1.1模式。 但是，问题不在于对这些分支进行版本控制。我不希望完全更改此版本控制方案。唯一的变化来自开发部门。主。如何在CI-CD环境中可靠地指示在生产中的先前发行版中存在哪个版本。理想情况下，这可以通过智能git标记完成，但最好不要过度标记master分支。
1
编程中的“解析”是什么意思？[关闭]
已关闭。这个问题是基于观点的。它当前不接受答案。 想改善这个问题吗？更新问题，以便通过编辑此帖子以事实和引用的形式回答。 4年前关闭。 我在很多地方Resolve都使用过这个词，例如在“依赖注入”（解析接口的实现），“包管理器”（例如：解析包的依赖关系），“ Web”（例如：解析主机名）中。 那么，是什么使代码的逻辑，特别是使一个人选择这个词Resolve在简单的Convert或者Transform甚至是Get？
2
如今如何模块化和打包客户端Javascript库？
我一直在追赶现代的客户端JS生态系统，并阅读CommonJS和AMD（包括相关工具-browserify，requirejs，onejs，jam等等）。如果我正在编写Javascript库，如何对它进行模块化/打包，以便可以最广泛地访问它（理想情况下，对CommonJS，AMD尤其是两者都不满意的用户）？ 像jQuery这样的流行库似乎只是使用老式文件串联来构建自身，并动态检测它是否应该写入exports或全局上下文。我目前正在做同样的事情，但是主要的缺点是，如果我（与jQuery不同）依赖于一些库，那么不必要求用户手动预先包含传递集就很好了。（尽管我目前只有两个依赖项。）当然还有全局名称空间污染。 还是为每个上下文生成我的库的多个版本是最干净的？ 我也想知道打包和发布。有几种系统，但是我相信主要的系统是bower，它很容易处理，因为它所做的只是获取。但是，我想知道是否也应该针对其他组件系统，例如component（需要CommonJS）。 我还应该注意其他相关方面吗？是否有所有这些都可以遵循的良好示例项目？
2
如何解决循环包装的依赖性
我正在重构一个大型代码库，其中大多数类位于一个包中。为了获得更好的模块化，我为每种功能都创建了子包。 我记得在某处学习过包依赖关系图不应包含循环的信息，但我不知道如何解决以下问题：Figure在package中figure，Layout在package中layout，Layout需要该图执行布局，因此package layout依赖于package figure。但另一方面，a Figure可以Figure在其内部包含其他s，它们具有自己的Layout，这使得package figure依赖于package layout。 我有一些解决方案，例如创建一个实现并将其放入包中的Container接口。这是一个好的解决方案吗？还有其他可能性吗？FigureLayout 谢谢
1
测试包的命名约定
实际上，我们正在像对测试包一样命名测试包。因此，我们最终得到以下结构： src/main/java com.hello.world helloWorld.java src/test/java com.hello.world helloWorldTest.java 我一直觉得这不是很聪明，因为如果仅提供包名称，则无法区分“测试”和“待测试”。另一方面，我还没有真正找到一个在某种程度上很重要的案例。这两个软件包（对于测试用例和源类）具有相同的命名约定是一种好习惯吗？如果没有，哪种方法更好？
11 naming  packages 
2
使用包（宝石，鸡蛋等）创建解耦的架构
主要问题 眼看着良好的支持最先进的编程平台有包管理（想想gem，npm，pip，等），它是有意义的设计应用程序或系统由内部开发的软件包，从而促进并创建一个松散耦合的架构？ 例 这样的一个示例是创建用于数据库访问以及用于身份验证和系统其他组件的软件包。当然，这些也使用外部程序包。然后，您的系统导入并使用这些软件包-而不是将其代码包含在自己的代码库中。 注意事项 对我来说，这似乎可以促进代码去耦并提高可维护性，几乎是一种基于Web的桌面应用程序方式（更新几乎是自动应用的，单一功能的单一代码库，等等）。 这看起来像是一个合理而理智的设计概念吗？如今，这实际上已用作构建应用程序的标准方法吗？
2
如何在用Java编写的API中封装内部类？
我们必须编写一个库。自然地，它应该只具有非常小的API（尽可能广泛且尽可能小的）。库的内部结构有些复杂。因此，它们需要结构化。 对于结构化，我目前看到两种方法： 1.使用包装。 优点：库可以结构整齐。一切都在其位置。 缺点：通过包边界使用类需要公共类，因此扩展了整个库的API。 2.使用静态内部类，全部在一个包中。 优点：只需要很少的公共事物（类，方法等）。 缺点：类被隐藏只是为了构造它们。这将是使用大量静态内部类的极少数用例之一。开发人员不习惯于此，可能会忽略它们。 有没有更好的方法来在结构良好的库中实现小型API？ 编辑：我忘了提及：这是一个Android库。因此，没有java9。
1
打包Python程序的良好做法
在个人和专业项目的背景下，我已经使用Python一段时间了。 最近发生在我身上的一件事是，我从未想过部署Python程序的好方法。基本上，因为它主要是一堆脚本，所以我通常只将它们复制到要部署它的机器上，瞧！ 但是我相信应该有一些关于如何部署Python项目的良好实践。我听说过Python Eggs，但对它并不熟悉，以了解它是否是一个不错的选择。还是带有一堆Shell脚本来运行核心模块脚本的普通老压缩包？ 基本上，我希望能够做一个很好，优雅且自包含的部署，而不仅仅是在这里和那里复制文件，因为它不允许轻易地进行版本跟踪，而且非常混乱。
By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.