大型组织的大规模前端架构( 三 )


但是是"甜"还是有缺点? 与任何解决方案一样 , 它也有缺点 。其中之一-将新工程师加入公司需要一些时间 。但是 , 如果一切都是以非常自然的方式完成的(就像人们已经习惯了其他现有工具一样)并记录在案 , 那么当您将其与开发速度的好处进行比较时 , 这并不是一个大问题 , 这是工程师合作的机会 任何代码库都很容易 , 等等 。
5.生产通常 , 在前端体系结构的这一部分中 , 工程师最不用担心 。也许是因为它大部分时间都与编码本身无关not并且可能并不那么令人兴奋 , 但同样重要least
在生产中 , 我们通常需要注意以下事项:
· Analytics(分析)各种不同的跟踪事件等 。 例如Google Analytics(分析) , Segment , HotJar等 。
· 状态监控这包括健康检查等内容 , 甚至可以在生产环境中运行测试 , 错误报告(例如Sentry)等 。
· A / B测试各种A / B测试解决方案或功能标记 。
· 缓存诸如Varnish , Cloudflare之类的工具 。
所有这些都可以在公司的前端应用程序中统一 , 这将简化工程师的工作 。例如 , 通过添加具有预定义的初始配置的软件包 , 并将这些软件包添加到自举项目中 。
生产的另一部分是代码准备 , 例如:
· 最小化代码最小化
· 源映射某些其他工具(例如Sentry)也可能需要源映射 。
· 资产准备为具有不同分辨率的屏幕 , 裁切图像等做准备 。
这些都是将要添加到我们用于管理前端应用程序的工具集中的不错的选择 , 我们在"工具"部分中已经讨论过 。
大型组织的大规模前端架构文章插图
> Production
概要:
理想情况下 , 默认情况下 , 所有这些都应在引导阶段添加到每个前端项目中 。工程师只关心在工具的正确位置添加正确的API密钥 。
6.发展CLI工具当我们接触前端CLI工具时 , 已经部分地在"工具"部分讨论了开发经验 。统一工具是工程师日常工作的重要组成部分 , 但不是全部 。
API在本地使用舒适的API是我们改善开发人员体验和开发速度的第二件事 。通常 , 为前端工程师在本地提供API的过程并不容易:这可能包括安装他们不熟悉的工具或框架 。即使通过泊坞设置进行安装 , 这也可能会占用开发人员计算机的大量计算资源(如果不是 , 则可以将其视为安装) 。在这种情况下 , 什么是解决方案-外部服务的API 。对于所有工程师来说 , 这可以是一台服务器 , 也可以是某种机制来轻松引导您自己的专用服务器进行开发 。
CICI是第三大部分 。我可能认为 , 您的公司已经为前端选择了一些CI工具并使用了该单一工具(例如Circle CI , Concourse CI或任何其他工具) 。如果不是 , 则应统一 。
我认为 , 特定项目的CI配置应该是该项目团队的一部分 。这给CI带来了稳定的机会 , 因为有些人对CI感兴趣 , 每天都要使用它 , 并且具有修复 , 配置和改进它的能力和技能 。
但是 , 并非所有工作都应由团队来完成 。对于前端应用程序 , 存在相当特定的一堆作业 , 这可能是需要的 。特别是 , 如果我们能够设法统一文件夹/代码结构 , 技术堆栈等 。 那么在您的公司中待了一段时间之后 , 也许您可以在CI工具的各个阶段检测到这些模式 , 将这些阶段实现为 某种"构建基块" , 并为您的工程师提供了一个机会 , 那就是从这些统一的"构建基块"构建其CI管道 。
演示环境最后是最后-验证实现的功能 。在工程师完成所有工作并实施之后 , 几乎总是需要某种方式来检查其外观和工作方式 , 并将其与其他工程师 , 设计师或其他利益相关者共享 。对于此类需求 , 它可以通过提供的URL在特定PR的应用程序的临时部署版本中发挥出色的作用 。
大型组织的大规模前端架构文章插图
> App temporarily deployed
该解决方案大大加快了不同团队与人员之间的沟通 , 我认为这是必须具备的 。但是 , 此临时部署的版本应尽可能接近生产环境 , 因为它也是检查某些表面错误或错误的好工具 。
如果您的前端应用程序构建和部署流程管道是统一的 , 则可以轻松地将其添加到您的项目中并自动进行 。同样 , 诸如Kubernetes和Helm之类的此类工具也可以在实现过程中提供很大帮助 。
大型组织的大规模前端架构文章插图
> Development
概要:
借助统一的CLI前端工具和演示环境 , 一个带有构建块的CI工具即可轻松高效地进行开发 , 以构建任何CI管道 。所有这些应使我们的开发过程尽可能顺利 。将其乘以您在公司拥有的工程师数量 , 您将了解它的好处 。