2015.1 技术雷达 | 技术篇

许多项目都存在外部代码依赖,这些依赖中很大一部分是由开源项目提供的。为了确保构建过程可被重现,我们总是与固定版本的外部依赖进行集成。但这就意味着我们与这些类库的新版本集成并不及时,这将导致后面大量的合并工作。我们见到的避免这个问题的方式之一是夜间的Canary Build,它会尝试使用所有外部依赖的最新版本进行构建。如果成功,就代表我们可以将外部依赖修改为相应的版本。

数据紧缩(Datensparsamkeit, martinfowler.com/bliki/Datensparsamkeit.html)来自于德国隐私法规,它表述了一种观点:仅保存在业务上或者合法性上绝对必要的个人信息。客户隐私依然是一个热门话题。像 Uber 这样的企业正在收集高度个人化的客户数据,然而他们的安全措施却非常糟糕(washingtonpost.com/blogs/the-switch/wp/2014/12/01/is-ubers-rider- database-a-sitting-duck-for-hackers)。这是一场注定要发生的灾难。即便是在尚无法律规定的地区,我们也应该尽量遵循数据紧缩的原则,或者使用“去身份识别技术”(en.wikipedia.org/wiki/De-identification)来减少所存储的信息——如果你根本就不保存这些信息,你也就用不着担心有谁会盗取它。

作为一种集成方式,通过HTTP使用ATOM风格的事件摘要(feed)最近受到了很多关注。大多数情况下我们并不需要维持一个实时更新的服务,使用旧式计划批处理进程来创建和发布摘要就够了。在和云技术结合后,比如Amazon的S3文件存储和超媒体链接,可以创建一个高度可用、简单而又可测试的解决方案。我们团队已经开始把这个新旧交替的方法叫做‘Hipster batch’。

当我们实现单页应用(single-page applications)时,“离线使用”这个问题迟早都会浮出水面。鉴于很难正确的将离线模式加入一个现有的应用中,“离线优先”的思想已经成为了开发单页应用的一种趋势。本地存储同步(local storage sync)就是一种我们曾经成功运用过的重要实现技术。使用这种技术,面向用户的代码将不再发送请求到后端系统,而是仅仅从本地存储(local storage)中获取数据。并由一个后台服务对本地存储和后端系统进行同步,通常,会调用某种形式的REST API。

NoPSD (thoughtworks.github.io/p2/issue02/continuous- design) 运动,旨在将设计活动整合进“迭代-反馈”循环中,以构建出优秀的软件。取这个名字,不是在讽刺Adobe的软件,而是要去除“PSD文件”这个“终极权威设计图”。团队不应在项目一开始就制定一个完美的像素级设计规范,而是要开始拥抱持续设计(Continuous Design):把设计师加入到交付团队中,使用低保真技术来做原型设计,并使用目标产品实际用到的UI技术(通常是HTML和CSS)来共同细化设计。

这种方法提高了对真实用户反馈的响应速度,支持横跨多种设备及其不同形态对设计进行测试,积极拥抱数码产品和产品创作过程的灵动本性。

依据团队边界分隔基础设施

我们的很多客户与负责构建、部署、支持他们的应用和服务的交付团队合作,在组织中实现了DevOps(技术运维)。然而不幸的是,在交付团队实施DevOps的道路上,经常会受困于生产环境中超级用户权限的归属问题。

在大多数组织中,生产环境是被共享的,因此提供宽泛的权限有很大的风险。一个行之有效的措施是将基础设施按照团队边界进行分隔,于是每个团队通过安全又相互隔离的访问进行工作,而不会影响到其他系统。如果是使用云环境,只需要对齐账户结构与团队边界,这种方式就更容易实现。

Middleman和Jekyll这样的静态网站生成器已经被广泛用于简单网站或博客的创建,同时我们也越来越多的看到它们成为更复杂技术栈的一部分。随着越来越多的团队开始尝试使用静态的预生成内容,认为“HTTP回复的内容只能根据请求来动态创建”的默认假设正在改变。

因为有像Clojure这样的函数式编程语言的默认支持,不可变数据结构(Immutable data structures)开始变得越来越流行。“不可变性”使得代码更容易被写、读和理解。使用“只追加”式的数据存储(append-only data store)同样带给数据库层面一些这方面的优点,同时也使得审计和历史查询更加简单。实现方式有很多种,从专门使用Datomic (datomic.com) 这样的“只追加”数据库,到简单以“只追加,不更新”的方式来使用传统数据库。

尽管比特币和其他各种密码货币(cryptocurrencies)现在备受关注,但让我们同样激动的是,Blockchain很有可能代替比特币和财务交易。Blockchain是一种不依赖于中央服务就能验证共享账簿的机制。我们已经看到Blockchain(不管是底层技术或是公开的比特币Blockchina)被用在身份验证、所有权、记录、投票、云存储甚至管理智能设备网络等各种系统的核心部分。如果你正在构建的系统需要在去中心化的网络中建立信任,那么Blockchain是一项值得尝试的技术。

一个企业级数据湖(Data Lake)是对大量原始格式的数据进行的不可变数据存储,它不仅作为其它处理流的资源,还可以为大量使用高效处理引擎的内部技术消费者(Consumer)—— 例如HDFS或基于Hadoop的HBase,Spark或Storm处理框架 —— 提供直接访问通道。与典型系统相比,这些系统会将原始格式的数据收集到严格受限的空间中,而且只会把严格受控的ETL过程生成的结果提供给这些消费者使用。

拥抱“数据湖”的理念就是要去除因缺少ETL开发人员或是堆积了太多前台数据模型设计而造成的瓶颈。它旨在帮助开发人员以敏捷的模式,基于他们需要数据的时机和方式(在合理的限度内),来创建他们自己的数据处理管道。这也与我们评价很高的另一模型——技术运维(DevOps)模型有很多相同点。

Gitflow是基于Git的一个严格的分支发布模式。虽然不是一个糟糕透顶的模式,但我们经常看到它被滥用。如果特性(feature)分支和开发(develop)分支是短暂并且频繁合并的,那么你确实是在发挥git的威力,它让团队合作变得更容易。然而,我们经常看到的一个问题是,这些“长寿分支”导致可怕的合并冲突,很多人重新开始使用git来避开这个问题。合并就是合并!无论你使用代码控制工具还是使用模式都不会改变这一点。如果你等一天或两天以上再合并,你就很有可能会遇到一个大的合并冲突。如果你在一个更大的团队中,这将成为一个真正的“问题”。如果你有更多的人在等待合并,这将进一步成为一个严重的瓶颈。成功引入像Gitflow这样的模式需要团队遵守“频繁合并、成功合并”的纪律。所以,当然可以使用这个模式,然而必须严格遵守“防止出现长寿分支”的纪律。

我们依然深信,在提高团队自主权和应对更加快速频繁的变更方面,微服务能给组织提供显著的优势。然而分布式系统所带来的额外的复杂性,需要更多的成熟度和投入。要做好微服务,就必须了解微服务给开发、测试和运维带来的变化。我们担心的是,一些团队在还没有弄清楚这些变化之前,就仓促地采用了微服务的方式。我们的建议非常简单,不要迷信微服务,在一股脑地开发更多微服务之前,从一个或两个服务开始,让你的团队有时间来调整并探索合理的微服务粒度。

我们仍然看到,一些团队会直接把复杂的多行命令插入到CI或CD工具的配置中。通常,这些内嵌的命令也包含了一些只在构建环境起作用的步骤,包括CI相关的环境变量,一些只会在CI环境创建、修改文件和模板的步骤,等等。这让构建环境变成了一头“怪兽”——其结果在开发人员的本地机器上是无法复现的。

这个问题之所以非常严重,是因为 — CI/CD工具本应该去暴露你代码中的问题,然而它自己却成为一个“复杂性怪兽”,其行为难以调试,结果也难以复现。

我们可以将复杂的构建过程提取成一个简单的脚本,这个脚本能通过一行命令来调用,这样就避免了在CI/CD工具中编程。它能够在任何一台开发者的机器上执行,这样也就消除了构建环境本身的独特性超。

把敏捷实践扩大到企业级,是一项持续的挑战。SAFe™在相关的众多方案中脱颖而出。虽然SAFe™为一些需要关注的方面提供了一份很有用的检查单,然而因为囊括了像“发布火车(release train)”和“门控流程(gated control processes)”这样已不再被敏捷社区认可的大型发布策略,此类方案往往容易被误用。企业倾向于寻找的具有一定程度通用性、可横跨多方努力的方案,看起来,这正是SAFe™所提供的,它所具有的某种程度的可定制性使它更具价值。事实上,其他的精益方案,比如像“改进道场(Improvement Katas)”这样,主张边试验、边持续改进的实践,为不断扩大敏捷实践的规模提供了一个更好的模型。

对于安全,传统的方式依赖于前期的规范以及最后阶段的验证。这种“安全三明治”的方式很难应用于敏捷团队,因为大部分设计都贯穿于整个过程,而且也没有利用到持续交付所提供的自动化便利。公司或组织应着眼于如何在整个敏捷开发周期中注入安全实践。这包括:正确评估威胁模型以做前期设计;考虑何时将安全问题划分为独立的故事(Story)、验收标准或全局的非功能需求;在构建流水线(Build Pipeline)中引入静态或动态的自动化安全测试;考虑如何将更深层的测试,如渗透测试,引入到持续交付的发布过程中。正如DevOps的出现使得过去相互博弈的团队能够重新合作一样,同样的事情也正发生在安全人员和开发人员身上。

原文发布于微信公众号 - 思特沃克(ThoughtWorks)

原文发表时间:2015-01-29

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏技术翻译

10必须了解托管云服务对业务增长的好处

根据MarketsandMarkets™关于托管云服务的报告,“云托管服务市场规模预计将从2017年的271.5亿美元增长到2022年的537.8亿美元,预计复...

1693
来自专栏Java社区

从0开发前后端分离的企业级上线项目

1902
来自专栏云计算D1net

DevOps在云中如何演变

Puppet和Chef这样的工具帮助人们在云上使用DevOps成为可能,但是当涉及到管理和分析云应用时,仍然会有障碍。 软件开发从一个应用程序的架构开始。传统的...

3378
来自专栏知晓程序

清单控必备!有了这款小程序,碎片时间也能轻松涨知识

今天,知晓程序(zxcx0101)就推荐一款碎片化阅读和知识分享平台「清单 plus」,让你在短时间内迅速收获经验和知识。

601
来自专栏Java学习网

论编程的最后期限

普通编程与专业编程之间有很多差别,而最为显著的就是截止日期。 截止日期 / 最后期限   当你给自己写程序的时候,只要你愿意,就可以用很多(或者很少)的时间来...

3437
来自专栏互联网数据官iCDO

Google Analytics增强版电子商务功能的分步指南

译者:陈荣芳、审校:朱玉雪 本文长度为3728字,预估阅读时间7分钟。 我们今天要向大家简单介绍下,如何使用Google Analytics增强版电子商务插件...

5554
来自专栏极乐技术社区

干货 | 小程序商城开发必读指南!

商城开发指南 ? ? 微信小程序商城模块 | 链接 使用zanui开发小程序微商城(模板组件的开发规范)| 链接 ecshop商城开发:用户信息的获取和缓存...

9895
来自专栏美团技术团队

数据库智能运维探索与实践

近些年,传统的数据库运维方式已经越来越难于满足业务方对数据库的稳定性、可用性、灵活性的要求。随着数据库规模急速扩大,各种NewSQL系统上线使用,运维逐渐跟不上...

1801
来自专栏软件测试经验与教训

张老师聊面试(二)

小梅,毕业一年,从实习到现在都在一家外包单位工作,做的是手机测试和定制软件的测试,由于工作单调,且没有成长空间,因此考虑换一份工作。但几次面试都不太顺利。

1041
来自专栏媒矿工厂

优化延迟的最佳视频传输方案(二)

上一篇文章《优化延迟的最佳视频传输方案(一)》介绍了在整个视频传输系统中的分发链前端和媒体内容准备方面的延迟优化方案,本文将继续介绍传输系统的接下来的优化方案,...

1682

扫码关注云+社区

领取腾讯云代金券