超级会员免费看
GitHub迁移、团队组织与企业转型全攻略
1. GitHub迁移要点
GitHub是一个复杂且快速发展的生态系统，任何形式的迁移都颇具挑战。在迁移时，应专注于在新平台上优化生产力，而非将所有内容迁移过去后让团队处理混乱局面。迁移情况会因组织规模和源平台的不同而有所差异。
1.1 迁移工具
以下是一些可助力迁移的工具及相关链接：
- GitHub Importer: https://docs.github.com/en/get-started/importing-your-projects-to-github/importing-source-code-to-github/importing-a-repository-with-github-importer
- GitHub Enterprise Importer CLI: https://github.com/github/gh-gei 和 https://docs.github.com/en/early-access/github/migrating-with-github-enterprise-importer
- GitHub Enterprise Server Importer: https://docs.github.com/en/enterprise-server@3.4/admin/user-management/migrating-data-to-and-from-your-enterprise/about-migrations
- ghe-migrator: https://docs.github.com/en/enterprise-server@3.4/admin/user-management/migrating-data-to-and-from-your-enterprise/about-migrations
- Tasktop: https://www.tasktop.com/
- git-svn: https://git-scm.com/docs/git-svn
- git-tfs: https://github.com/git-tfs/git-tfs
2. GitHub团队组织最佳实践
2.1 GitHub范围和命名空间
GitHub的主要实体是仓库，可针对用户或组织创建。仓库URL格式如下：
- 针对用户： https://github.com/<username>/<repository>
- 针对组织： https://github.com/<organization>/<repository>
对于GitHub Enterprise Server，需将 https://github.com 替换为服务器的URL。平台上的用户和组织名称必须唯一，因为它们提供了命名空间，而仓库名称在该命名空间内也必须唯一。
2.2 GitHub企业
在GitHub中，企业是多个组织的容器。企业不是命名空间，组织名称仍需唯一。企业有一个URL段用于引用企业，其URL格式为： https://github.com/enterprises/<enterprise-slug> 。
若拥有按发票付费的组织，可在“Settings | Billing and plans”中升级为企业；否则，需联系GitHub销售。GitHub企业有以下三种角色：
| 角色 | 权限 |
| ---- | ---- |
| 所有者 | 对企业有完全管理权限，但对组织没有 |
| 成员 | 至少对一个组织有访问权限的成员或外部协作者 |
| 计费管理员 | 仅能查看和管理计费信息 |
企业级可配置一些适用于所有组织的设置，如SAML身份验证、SSH证书颁发机构或IP允许列表等，还有企业级的Webhook，可访问整个企业的审计日志。审计日志流式传输到云存储、Splunk或Azure事件中心仅在企业级可用，不过大多数设置围绕计费和许可。此外，还可为组织级可配置的许多设置制定策略，若已设置策略，组织所有者无法更改设置；若未定义策略，组织所有者可配置该设置。
2.3 GitHub组织
管理仓库和团队的主要方式是使用组织。组织可独立于企业存在，也可在不同企业间移动。组织不应作为团队自我组织的自助服务。一些公司拥有超过2000个组织，这会带来管理集成方面的大问题，例如GitHub应用只能在组织级配置，不能在企业级配置。若要与Jira实例进行集成配置，必须为所有组织分别进行，无法在企业级配置。
大多数情况下，一个组织就足够。若公司有不同的法律实体需要分开，或者想分离开源和内部开源，可设置多个组织，但不应为每个部门或部门设置一个组织，使用团队来实现更好。组织有以下角色：
| 角色 | 权限 |
| ---- | ---- |
| 所有者 | 对团队、设置和仓库有完全访问权限 |
| 成员 | 可查看成员和非秘密团队，还可创建仓库 |
| 外部协作者 | 不是组织成员，但可访问一个或多个仓库 |
组织拥有项目、包、团队和仓库，可配置仓库的许多设置。若未在组织级配置这些设置，可在仓库级设置。
2.4 构建GitHub团队
团队不仅是授予仓库权限的便捷方式，可实现更快的入职和离职，还可用于知识共享和通知特定组的变更。团队有讨论功能，可查看其仓库和项目。团队有以下两种可见性：
- 可见：组织的每个成员都能看到并提及可见团队。
- 秘密：只有团队成员能看到秘密团队，且不能嵌套。
团队存在于组织的命名空间中，这意味着团队名称在组织内必须唯一。可使用 @<organization>/<team-name> 的语法提及团队或添加其为代码所有者。
可通过嵌套团队来反映公司或团队的结构，创建新团队时指定父团队，新团队即为子团队，子团队也可成为父团队，从而创建深层层次结构。团队从父团队继承权限和通知，但反之则不成立。通过嵌套团队，可创建公司结构，如为所有员工、每个部门、每个产品团队（垂直团队）创建团队，也可为兴趣小组（如实践社区）创建水平团队。
graph LR
classDef process fill:#E5F6FF,stroke:#73A6FF,stroke-width:2px;
A(所有员工团队):::process --> B(部门A团队):::process
A --> C(部门B团队):::process
B --> D(产品A团队):::process
B --> E(产品B团队):::process
C --> F(产品C团队):::process
G(实践社区团队1):::process --> A
G --> B
G --> C
团队可在组织的“Teams”选项卡中展开，有讨论页面，组织成员可参与团队讨论，团队也可进行组织其他成员不可见的私人讨论。团队可被提及、分配为审查者和代码所有者，是简化组织结构的强大工具，但要尽量保持简单，使用易于理解的名称。
2.5 基于角色的访问
在仓库级，可向团队或个人授予基于角色的访问权限，可使用以下默认角色：
| 角色 | 权限 |
| ---- | ---- |
| 读取 | 读取和克隆仓库，打开并评论问题和拉取请求 |
| 分类 | 读取权限，外加管理问题和拉取请求 |
| 写入 | 分类权限，外加读取、克隆和推送至仓库 |
| 维护 | 写入权限，外加管理问题、拉取请求和配置一些仓库设置 |
| 管理 | 对仓库有完全访问权限，包括敏感和破坏性操作 |
需注意，读取角色不仅能读取，还能打开并评论问题和拉取请求。分类和维护是开源项目中的典型角色，在企业场景中不太常用。可设置组织的基本权限为读取、写入或管理，这将授予所有成员对所有仓库相应的权限，但外部协作者不继承基本权限。
2.6 自定义角色
可在组织设置的“Repository roles (/settings/roles)”中定义自定义角色。点击“Create a role”，指定新角色的名称和描述，然后选择一个默认角色继承权限并添加权限。权限按以下类别划分：
- 讨论
- 问题
- 拉取请求
- 仓库
- 安全
并非所有内容都可配置，例如目前没有针对GitHub包的特定权限。若一个人被授予不同级别的访问权限，较高权限总是覆盖较低权限；若一个人被授予多个角色，GitHub上该人员旁边会出现“Mixed roles”警告。尽量保持自定义角色简单。
2.7 外部协作者
外部协作者是不属于组织但可访问一个或多个组织仓库的人员。需注意，向私有仓库添加外部协作者会消耗一个付费许可证。外部协作者不是组织成员，看不到内部仓库，也不继承基本权限。不能在组织级邀请外部协作者，只能邀请成员加入组织，然后将其转换为外部协作者。作为仓库管理员，在“Settings | Collaborators and teams”中添加人员时，若他们已属于组织，将自动添加为成员；否则，将添加为外部协作者。外部协作者是与合作伙伴和客户轻松协作的好方法，但如果使用企业管理用户则不适用。若启用了SAML单点登录，外部协作者会绕过该机制，因此组织所有者可在组织设置中阻止仓库管理员邀请外部协作者到仓库。
3. 企业转型要点
3.1 转型失败的原因
软件是各行业产品和服务的核心，从客户体验到供应链管理都离不开它。这意味着许多企业需要转型成为数字化高性能公司，但很多转型都以失败告终。以下是一些常见的失败原因：
3.1.1 认为公司或行业特殊
很多人认为自己的公司或行业独一无二，但在数字化转型方面并非如此。无论产品是否可能造成人员伤亡、是否需要遵守特定标准、是否是军工产品、是否公开交易或为政府工作，在DevOps转型中面临的挑战和规则与其他公司并无本质区别。相关研究表明，这些规则适用于所有公司，从初创企业到大型企业，从前沿互联网公司到高度监管的行业，如金融、医疗和政府等。这其实是好事，意味着很多转型中遇到的问题已被其他公司解决，可借鉴他们的经验，避免重蹈覆辙。
3.1.2 缺乏紧迫感
变革的最大阻碍是自满。如果企业中的人员自满，就会抵制变革，继续按老方式做事。必须让人们真正感受到紧迫感，去解决关键问题。这里的紧迫感不是管理层施加的造成焦虑的压力，而是一种驱使人们带着必胜决心去改变的动力。没有真正的紧迫感，人们会抵制变革，更可能维持旧有行为。不同层级的人员产生紧迫感的原因可能不同，管理层可能感受到市场压力和频繁发布产品的灵活性不足，工程师可能感受到技术债务和因旧流程和工具导致的人才吸引与保留问题。重要的是用清晰的愿景将这些不同的紧迫感根源统一起来，形成一股同向的驱动力，避免不同力量相互抵消。
3.1.3 缺乏清晰的愿景
更换工具、流程和角色相对容易，但改变行为、文化和理念却很难。没有清晰的愿景，转型就无法达到预期效果。如果听到有人说“我们不是微软或谷歌，也不是前沿互联网公司”，这表明他们缺乏清晰的愿景。如果愿景明确表示要成为行业的数字领导者，或者从产品公司转变为服务公司，人们就不敢说与之相悖的话。一个好的推动变革的愿景应该是清晰且有吸引力的，说明所有转型的目标方向。需要注意的是，DevOps转型并不总是由高层管理推动，很多公司的转型由个别部门甚至团队发起，但同样需要清晰的愿景和紧迫感来确保转型成功。
3.1.4 让障碍阻碍进展
开始转型时，会遇到很多阻碍。例如某些行业的特定法规，像ISO26262或GxP等建议采用软件工程项目的V模型，而V模型基于瀑布模型，与多年的DevOps研究成果相悖。如果坚持使用瀑布模型，DevOps转型很可能失败，但这往往是对法规的内部解读问题。仔细研究法规会发现，它们只是坚持最佳实践，如果自身实践优于推荐实践，可进行合理说明并通过审计。大多数遇到的障碍是由组织自身造成的，如组织结构、严格的工作类别、流程或工会与管理层之间的矛盾等。不能让这些障碍阻碍转型。
3.2 转型的建议
为了成功实现企业转型，可参考以下建议：
- 借鉴经验 ：认识到自身并非特殊，积极从其他成功或失败的转型案例中学习，避免重复他人的错误。
- 营造紧迫感 ：在组织内营造真正的紧迫感，确保不同层级的人员都能感受到转型的必要性，并将各自的紧迫感统一到共同的愿景下。
- 明确愿景 ：制定清晰、有吸引力的转型愿景，让组织内的每个人都明白转型的目标和方向。
- 克服障碍 ：不被组织内部的障碍所束缚，积极寻找解决办法，确保转型顺利进行。
3.3 转型流程总结
以下是企业转型的大致流程：
graph LR
classDef process fill:#E5F6FF,stroke:#73A6FF,stroke-width:2px;
A(认识转型需求):::process --> B(分析自身情况):::process
B --> C(借鉴他人经验):::process
C --> D(营造紧迫感):::process
D --> E(明确转型愿景):::process
E --> F(制定转型计划):::process
F --> G(克服转型障碍):::process
G --> H(实施转型):::process
H --> I(持续评估和改进):::process
总之，通过合理运用GitHub的迁移和团队组织功能，以及正确应对企业转型中的各种挑战，企业可以逐步建立起具有工程文化、提高开发者速度的数字化高性能企业，加速DevOps在组织中的应用，提升整体竞争力。
扫一扫
660
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
