ROSE 编译器框架/工作流程
外观
ROSE 工作流程的目标是拥有一个简化、简化和自动化的流程,以允许用户和开发人员
- 提高 ROSE 源代码和文档的质量
- 提高我们的生产力,使我们能够以比平时更少的时间和资源来完成高质量的工作
开发大型、复杂的项目会遇到很多挑战。为了减轻其中一些挑战,我们采用了一些最佳实践:增量开发、代码审查和持续集成。
- 迭代和增量软件开发,用于早期结果、可控风险和更好地参与利益相关者
- 代码审查,用于一致性、可维护性、可用性和质量
- 持续集成,用于自动化测试、轻松发布和可扩展的协作
以小步骤开发新功能,其中每一步产生的代码都是对先前状态的有用改进。与完全阐述整个功能形成对比,在此过程中没有外部可用的点。
每个 ROSE 开发人员都应至少每三周将自己的工作提交一次。
增量开发的主要好处
- 您可以在路径上获得中间结果。因此,您的赞助商可以睡得更香。
- 您将尽早并经常获得有关您是否朝着正确方向前进的反馈。
- 您的工作将经常被测试并合并到主分支中,避免了合并冲突的风险。
查看有关如何增量处理项目的更多提示
请参阅ROSE 中的代码审查。
尽可能频繁地将正在进行的工作中的更改合并到共享主线中,以便尽早识别不兼容的更改和引入的错误。就系统其余部分而言,集成更改不必是特定功能增量。
换句话说,增量开发是关于尽早使自己的工作有价值,以及可能关于更好地了解它应该采取的方向,而持续集成是关于减少由于多人在并行开发代码库分歧而产生的风险。
是否对新代码进行条件化是一个有趣的问题。通过这样做,一个人将持续集成的范围缩小到只检查合并更改代码时的表面不兼容性。如果没有实际针对现有测试运行新代码,那么尽早检测引入的错误就会丢失。作为交换,在代码库的同一部分中工作的多个人不太可能互相踩脚,因为相关的代码更改会更快地传播。
在持续集成中了解更多信息
外部
- 外部 (https://github.com/rose-compiler/rose): 开始一个待讨论的问题
- 维基教科书
- 收集社区意见
- 邮件列表:与用户的互动,感受用户的需求
内部:需要 LC 帐户才能访问
- JIRA: https://lc.llnl.gov/jira
- 电子邮件界面:发送至 : [email protected],抄送至分配者
- Confluence: https://lc.llnl.gov/confluence/
- 维基教科书:基于社区的设计文档并激发讨论
- Powerpoint 幻灯片:关于设计的更正式的沟通
- Confluence: https://lc.llnl.gov/confluence/
- Redmine (http://hudson-rose-30:3000/): 基于里程碑和用户输入创建项目,创建和跟踪任务
- 特定于项目的任务
- 私有问题跟踪
- 私有文档
- 使用 Redmine 的维基
- Github
- 内部 (http://github.llnl.gov/): 仅用于代码审查,
- 外部 (https://github.com/rose-compiler/rose): 公共托管代码,公共问题跟踪,用于一般 ROSE 错误和功能。
- “Rosebot” 自动化 Github 工作流程:初步测试、策略(git-hooks)、自动添加审阅者等。
- Jenkins ((http://hudson-rose-30:8080/)): 新功能的持续集成,错误修复
- https://rosecompiler1.llnl.gov:8443/jenkins-edg4x/ EDG 4.x 分支工作的新 Jenkins 实例
- 在ROSE 编译器框架/文档中了解更多信息
- 网站 (http://www.rosecompiler.org): 与所有其他组件连接的内容管理系统
重大工作流改进和更改在部署之前应由工作人员彻底测试和审查,因为它们可能会对项目产生深远影响。
如何提议工作流更改
- 在 github.com 的 rose-public/rose 问题跟踪器上提交一个工单。在工单中,提供以下信息
- 是什么:解释提议的更改是什么
- 为什么要更改:对我们生产力和工作质量的长期益处
- 更改的成本:学习曲线、可维护性、购买成本
- 优化
- 优化我们的工作流程,使我们能够以更高的质量完成更多工作,并减少时间和其他资源的消耗。
- 解决拖慢我们的速度或分散我们注意力的因素。
- 简化日常生活。比较我们可以如何通过提议的工作流改进消除或自动化流程。
- 通过在日常工作中添加更多环节/步骤/点击来改进工作流程是适得其反的。
- 改进
- 允许逐步提高工作质量。
- 接受逐步改进比要求第一次就达到完美更现实。
- 工作流程应允许快速的新贡献和对现有贡献的快速修订。
- 自动化
- 工作流程的添加应尽可能自动化。
- 保留
- 它必须保留现有工作。
- 不要从头开始创建任何内容。
- 它是否与现有工作流程很好地交互
- 是否有将现有代码/文档转换为新形式的方法
- 它必须保留现有工作。
- 简单
- 我们依赖的软件工具越多,使用和维护我们的工作流程就越困难。同样,我们强制执行的格式/标准越多,开发人员进行日常工作就越困难。
- 在我们的工作流程中采用新的必需软件组件和新的必需技术格式/标准应经过非常仔细的审查,以评估相关的**长期益处**和成本。长期是指 5 到 10 年的范围,不与我们现在使用的临时事物绑定。
- 主要贡献者的偏好:贡献最多的人应该有更大的发言权。
- 文档:我们要求重大更改在部署之前进行文档化和审查。写下东西可以帮助我们澄清细节并征求更广泛的意见(而不是局限于面对面的会议)。