项目管理 (Project Management)

双剑合璧：结合GitHub与Google Workspace的项目管理艺术 之前写过一篇 从理论到实践的项目管理打通 。 其中介绍了 Github 的项目管理方式 Github Projects，以及配合 Github 实现整个开发和项目管理打通，但是可能会出现一些问题，今天来聊聊其中会出现的问题，以及给出对应的解决方法，顺便总结一下现阶段自己认为的开源项目做项目管理的最佳实践方法。 google projects VS github projects GitHub Projects 针对开发者：GitHub Projects特别适用于软件开发项目，因为它紧密集成了GitHub的代码仓库、问题跟踪（Issues）和拉取请求（Pull Requests）。 项目管理功能：提供看板（Kanban）和项目里程碑跟踪，便于管理项目的进度和任务。 开源友好：对于开源项目尤其友好，使得与全球开发者的协作变得简单。 集成和自动化：通过GitHub Actions，可以实现持续集成和持续部署（CI/CD）等自动化流程，与项目管理紧密结合。 Google Projects Google Workspace集成：如果你已经在使用Google Workspace（前身为G Suite），那么Google Projects（指的是Google的某些项目管理工具，如Google Tasks或者更广泛的Google Workspace应用）可能提供更好的集成体验。 通用项目管理：可能更适合非软件开发的项目管理，如营销活动、HR项目等（如Google Docs、Sheets、Slides等）。 协作和共享：Google应用的强项在于实时协作和文件共享，适合需要紧密协作的项目团队。 以前是单打独斗，或者是简单的开发小团队，那么 Github Projects 必然是最合适的，如今需要考虑到更多人的参与，更有序的资源和文档的管理，那么对于现在来说，可能需要更多的优化协作。 比如说一些重要的文档记录，一些重要的表格，以及 PPT 演示，会议记录，以及一些日程安排。但是对项目本身来说，结合Github问题追踪和拉取请求又非常重要。 我希望组合使用GitHub Projects和Google Projects（或Google Workspace的相关工具）进行项目管理，可以根据各自的优势制定一个最佳实践方案。这样做可以充分利用两个平台的优点，实现更高效和全面的项目管理： 1. 使用GitHub Projects管理开发活动 代码管理和追踪：利用GitHub的核心优势，将所有代码管理任务（包括版本控制、分支管理等）以及与代码直接相关的活动（如Bug追踪、功能请求等）保留在GitHub。 自动化工作流：通过GitHub Actions实现自动化，比如自动测试、构建和部署，以及自动化的问题和拉取请求管理。 项目看板：使用GitHub Projects的看板功能跟踪开发进度，如待办事项、进行中和已完成任务。 2. 利用Google Workspace管理项目的其他方面 文档和文件共享：使用Google Docs、Sheets和Slides来创建和共享项目文档、计划和报告，利用它们强大的实时协作功能。 通信和会议：通过 Google Meet 和 Gmail 进行项目会议、沟通和更新，保持团队成员之间的紧密联系。 任务和日程管理：利用 Google Tasks 和 Calendar 管理非开发任务（如市场活动、人力资源计划等）以及重要的项目里程碑和会议安排。 最佳实践方案 集成工具使用：探索和使用第三方工具或脚本实现GitHub和Google Workspace之间的数据同步。例如，可以自动同步GitHub Issues到Google Sheets作为任务列表，或者在GitHub里程碑变更时自动更新Google Calendar。 明确分工和规范：在项目开始时明确规定哪些任务和活动应该在GitHub上管理，哪些应该使用Google Workspace工具。制定明确的团队协作和沟通规范，确保所有项目成员都清楚使用哪个工具以及如何使用。 定期检查和调整：项目管理方法和工具的选择应根据项目的实际情况进行调整。定期回顾团队的工作流程和工具使用情况，根据反馈和项目需求进行必要的调整。 谷歌项目管理工具：所有你需要知道的 对于 Github 的项目管理，可以阅读 从理论到实践的项目管理打通 ，以及 Github Projects 官方网站 https://docs....

会议和参考链接 会议参考文档：https://nsddd.notion.site/2899028707604b8090b36677c031cdf8?pvs=4 视频回放：Bilibili: https://www.bilibili.com/video/BV1s8411q7Um/?spm_id_from=333.999.0.0 评论： 那个中间件我觉得可以换成 https://kubeblocks.io 可以帮你管理多个数据库中间件 im 读取配置信息，读取的是 config/ 目录，代码中硬编码补充的 config.yaml，是否可以自动化来对 不同 服务的 rpc 划分，然后统一目录，默认读取的是二进制运行路径的上两层 openim version: https://github.com/openimsdk/open-im-server/blob/main/docs/conversions/version.md 存储可以考虑使用 ： https://github.com/openebs/openebs https://github.com/rook/rook 核心目标： 开源项目和非开源项目的最大的区别，就是一套完整的解决方案。 非开源项目的 集群化部署方案的设计，比较在乎稳定，以及高效，快速，最好一键部署。 开源项目的 集群化部署方案的设计，比较在乎通用性，上手的难度，后期的维护难度，基础架构的稳定性。后面的开发者或者是贡献者，使用者，可以基于此创建自己的集群化部署方案，以及解决方案，并且成为 OpenIM 的集群化部署方案的使用案例。 OpenIM 集群化部署讨论会记录 先总结，后详细解读 ~ 关于开源部署环境的演变与变化 新部署方法：一种集二进制和部署于一体的一键操作。 Kubernetes 部署：在 Kubernetes 环境中实现一键部署的新型方案。 现存问题：涉及日志收集、服务重启追踪等，将在后续对这些问题进行改进并寻求解决方案。 CICD的开发与维护策略 CICD 概念：通过CICD实现Code Streaming。 开发阶段：需要编写出镜像文件。GitHub的CSD功能：已实现但尚待深入研究。 版本标记策略：推荐使用local branch而非直接标签。 关于软件开发与测试的实践经验分享 本地开发：推荐使用“auto-compile”工具快速生成稳定版本的镜像。 团队协作：介绍了各团队间如何协同进行开发、测试和发布。 代码重用：提及将库中的函数或方法封装为组件，实现跨项目调用。 Docker Deployment与Service Configuration 配置传递：主要通过如K8S中的配置文件。 部署方式：介绍了二进制部署和可部署两种策略，并讨论了各自的优缺点。 关于容器化部署和代码优化的探讨 容器化：提议将多个进程合并为一个容器进行管理。 部署方式兼容性：讨论了如何实现并进行微调。 技术架构和组件：如Helm chat、OpenM等，及其在系统中的作用和重要性。 关于一键部署的技术问题与解决方案 一键部署问题：可能的问题有无法翻墙、无法安装等。 解决方案：1) 将现有方案通用化；2) 采用第三方服务实现一键部署。 K8S部署与自动化的优化策略 部署工具：如使用Shell实现一键部署、K ks部署等。 组件整合：考虑如何将不同组件组合成完整解决方案，并保持不同环境中的一致性。 微服务架构中的最佳实践 应用程序部署：建议将应用程序划分为不同的容器，每个容器内运行一个业务进程。 代码整合：提议将相关代码整合为一个文件进行管理。 微服务的优化与部署策略 微服务划分：强调避免过于细致的模块分割。 自动化：部署时不增加额外维护工作量，采用自动化策略。 关于存储方式和编排工具的选择 文件存储：如使用NFS作为本地分布式文件存储。 编排工具：推荐使用 rook 进行对象存储编排，数据库使用专用编排器。 NFS与Flexible File System的应用 苹果手机上的MFS：讨论了其使用情况和如何同步全局配置文件到各业务模块。 PV/PVC管理数据：示例讲解如何使用此文件系统进行数据管理。 二进制代码与配置文件的应用 代码适配：通过配置文件进行，涉及传递配置路径、文件映射等细节。 关于软件开发中的优化与改进 项目脚本编写：讨论了性能瓶颈、部署统一处理、服务发现模块的优化建议。 关于Web应用配置文件的编写与优化 IP分配：配置文件用于IP分配和模块间分段处理。 接口应用：如在不同环境使用不同的接口实现心跳等功能。 技术架构改进：优化轻量化、提高开发效率和维护效果等。 结论：本次讨论会涉及了开源部署环境的多个方面，从软件开发、部署、测试到微服务架构和存储方式等多个领域。希望通过此次讨论，可以为OpenIM的集群化部署提供有力的参考和指导。...

重新搭建我的博客（静态） 冤大头回来了 … 太难了这次，准备简历的时候，发现我的博客没了，我最亲爱的，陪伴了一年的，备受好评的博客 nsddd.top 牺牲了 呜呜呜呜 别急别急，吸取教训，第一件事是什么，坚决不用动态博客了，从大一的第一代博客使用 workpress， 那时候用的服务器管理工具是 著名顶顶的 宝塔 ， 虽然现在我还在用，哈哈哈，不过以后绝对绝对不会再用了 。第二代博客还记得吗 ，第二代博客就是我刚刚牺牲掉的博客，使用 docker 搭建，存活了两年（大二到大三），服务器中途都换了一次，不过得益于 Docker 优雅的移植性haha，所以我的博客得以存活。 那这次为啥挂了？？？ 挂的时间是 2023 年 9 月 1 日。原因是 Java 出现故障，发现 swtich 空间不足，然后，准备移植的，修复的，实在是觉得无力维护，我希望我的博客可以长久生存几年，十几年，甚至是几十年上百年。 所以，从头开始 !!! 选择合适的博客模板 之前用过 vuepress 做笔记，vuepress 相对来说不是特别合适我现在做的，因为已经有视觉疲惫了哈哈哈，看着很不舒服，所以用我很喜欢的一个开源项目，大家很多人也耳熟能详的顶级开源项目：hugo , GitHub 地址是：https://github.com/gohugoio/hugo 接下来就是选择合适的主题了，我参考了几个热门的 theme 选择了 https://github.com/adityatelange/hugo-PaperMod 安装 Hugo 我热衷于源码，可以随时改代码，提 PR ，于是用源码构建： ❯ git clone https://github.com/cubxxw/hugo.git ❯ cd hugo ❯ go build ❯ mv hugo /usr/bin 部署主题 选择我们使用的主题： ❯ git clone https://github....

DevOps DevOps 🔥 DevOps是一种软件开发和运营的文化和方法论，旨在通过自动化和协作来缩短软件开发周期和提高软件质量。 DevOps（Development和Operations的混成词）是一种重视“软件开发人员（Dev）”和“IT运维技术人员（Ops）”之间沟通合作的文化、运动或惯例。通过自动化“软件交付”和“架构变更”的流程，来使得构建、测试、发布软件能够更加地快捷、频繁和可靠。 为什么 OpenIM 需要 DevOps？ 我想用一句话来概括，DevOps 能解决 OpenIM 当前的团队管理，能高效组织团队，并且能通过 自动化 工具协作于沟通。 从而实现用更少的浪费、更频繁的交付更稳定的产品。 最开始的 OpenIM 是什么样子的？ 找到了之前的一个很古老的版本，链接是：https://github.com/OpenIMSDK/Open-IM-Server/tree/test-tuoyun 几乎存在 commit 信息丢失，因为信息不全导致代码无法跟踪问题，导致文档缺失，代码不规范等一系列的问题。 我们跨越了从原始社会到传统的协作方式，再到后面的 devops 为什么说及时到现在，我依旧没有将 OpenIM 转变为 devops，一个很明显的判断标准，每一次运维和交互工作依旧需要我手动去做，无疑是区分了 dev 和 ops 的职责。不仅仅让成本变高，效率变低，更重要的是团队没有了更清晰的定位。 那么我后面的计划如何？ 不管是 prow, actions, 等等 CI 工具，以及各种 ops（gitops, aiops, chatops,） 也不管是各种设计的 自动化 以及 自动化管理工具，自动化交互工具。 无疑他们是一套体系： 提供无感知的开发环境，无论交付是否频繁，每一个 feature 的 PR 都能快速的，规范并且经过大量自动化测试，更加快速上线，也能更快地响应客户需求。每一次发布的变更变少，所以风险，以及合并的冲突，工作量就变少。而且代码 code review 更方便，代码质量和团队水平提升很高的档次。 🔥 OpenIM 当时我的设计理念是 main 分支作为一个类似于传统的 dev 分支，保证代码的最新以及基本可靠，release-v* 分支作为稳定的分支。 DevOps 最重要的就是自动化，和自动化运维。非常鼓励自动化，甚至可以让开发者即使不会任何运维也能去走整套自动化的流程。 OpenIM 的团队约束制定：https://traveling-thistle-a0c.notion.site/OpenIM-standardization-ebd0c1529ab54e4fb92840e67a73aac1?pvs=4...