Arch 用户你们好！今天，我偶然发现了一个叫做 “ArchI0” 的实用工具，它是基于命令行菜单的 Arch Linux 应用自动安装脚本。使用此脚本是为基于 Arch 的发行版安装所有必要的应用最简易的方式。请注意此脚本仅适用于菜鸟级使用者。中高级使用者可以轻松掌握如何使用 pacman来完成这件事。如果你想学习如何使用 Arch Linux，我建议你一个个手动安装所有的软件。对那些仍是菜鸟并且希望为自己基于 Arch 的系统快速安装所有必要应用的用户，可以使用此脚本。

ArchI0 – Arch Linux 应用自动安装脚本

此脚本的开发者已经制作了 ArchI0live 和 ArchI0 两个脚本。你可以通过 ArchI0live 测试应用，无需安装。这可能有助于在将脚本安装到系统之前了解其实际内容。

安装 ArchI0

要安装此脚本，使用如下命令通过 Git 克隆 ArchI0 脚本仓库：

$ git clone https://github.com/SifoHamlaoui/ArchI0.git

上面的命令会克隆 ArchI0 的 Github 仓库内容，在你当前目录的一个名为 ArchI0 的文件夹里。使用如下命令进入此目录：

$ cd ArchI0/

使用如下命令赋予脚本可执行权限：

$ chmod +x ArchI0live.sh

使用如下命令执行脚本：

$ sudo ./ArchI0live.sh

此脚本需要以 root 或 sudo 用户身份执行，因为安装应用需要 root 权限。

注意： 有些人想知道此脚本中开头的那些命令是做什么的，第一个命令是下载 figlet，因为此脚本的 logo 是使用 figlet 显示的。第二个命令是安装用来打开并查看许可协议文件的 Leafpad。第三个命令是安装用于从 sourceforge 下载文件的 wget。第四和第五个命令是下载许可协议文件并用 leafpad 打开。此外，最后的第 6 条命令是在阅读许可协议文件之后关闭它。

输入你的 Arch Linux 系统架构然后按回车键。当其请求安装此脚本时，键入 y 然后按回车键。

一旦开始安装，将会重定向至主菜单。

正如前面的截图， ArchI0 包含有 13 类、90 个容易安装的程序。这 90 个程序刚好足够配置一个完整的 Arch Linux 桌面，可执行日常活动。键入 a 可查看关于此脚本的信息，键入 q 可退出此脚本。

安装后无需执行 ArchI0live 脚本。可以直接使用如下命令启动：

$ sudo ArchI0

它会每次询问你选择 Arch Linux 发行版的架构。

This script Is under GPLv3 License

Preparing To Run Script
 Checking For ROOT: PASSED
 What Is Your OS Architecture? {32/64} 64

从现在开始，你可以从主菜单列出的类别选择要安装的程序。要查看特定类别下的可用程序列表，输入类别号即可。举个例子，要查看文本编辑器分类下的可用程序列表，输入 1 然后按回车键。

This script Is under GPLv3 License

[ R00T MENU ]
Make A Choice
 1) Text Editors
 2) FTP/Torrent Applications
 3) Download Managers
 4) Network managers
 5) VPN clients
 6) Chat Applications
 7) Image Editors
 8) Video editors/Record
 9) Archive Handlers
 10) Audio Applications
 11) Other Applications
 12) Development Environments
 13) Browser/Web Plugins
 14) Dotfiles
 15) Usefull Links
 ------------------------
 a) About ArchI0 Script
 q) Leave ArchI0 Script

Choose An Option: 1

接下来，选择你想安装的程序。要返回至主菜单，输入 q 然后按回车键。

我想安装 Emacs，所以我输入 3。

This script Is under GPLv3 License

[ TEXT EDITORS ]
 [ Option ] [ Description ]
 1) GEdit
 2) Geany
 3) Emacs
 4) VIM
 5) Kate
 ---------------------------
 q) Return To Main Menu

Choose An Option: 3

现在，Emacs 将会安装至你的 Arch Linux 系统。

所选择的应用安装完成后，你可以按回车键返回主菜单。

结论

毫无疑问，此脚本让 Arch Linux 用户使用起来更加容易，特别是刚开始使用的人。如果你正寻找快速简单无需使用 pacman 安装应用的方法，此脚本是一个不错的选择。试用一下并在下面的评论区让我们知道你对此脚本的看法。

就这些。希望这个工具能帮到你。我们每天都会推送实用的指南。如果你觉得我们的指南挺实用，请分享至你的社交网络，专业圈子并支持我们。

干杯！

via: https://www.ostechnix.com/archi0-arch-linux-applications-automatic-installation-script/

作者：SK 选题：lujun9972 译者：fuowang 校对：wxy

本文由 LCTT 原创编译，Linux中国 荣誉推出

最近我在用我编写的各种工具做更多 UNIX 下的事情，我遇到了两个有趣的问题。这些都不是 “bug”，而是我没想到的行为。

线程安全的 printf

我有一个 C 程序从磁盘读取一些图像，进行一些处理，并将有关这些图像的输出写入 STDOUT。伪代码：

for(imagefilename in images)
{
    results = process(imagefilename);
    printf(results);
}

对于每个图像都是独立处理的，因此我自然希望将处理任务分配在各个 CPU 之间以加快速度。我通常使用 fork()，所以我写了这个：

for(child in children)
{
    pipe = create_pipe();
    worker(pipe);
}

// main parent process
for(imagefilename in images)
{
    write(pipe[i_image % N_children], imagefilename)
}

worker()
{
    while(1)
    {
        imagefilename = read(pipe);
        results = process(imagefilename);
        printf(results);
    }
}

这是正常的做法：我为 IPC 创建管道，并通过这些管道给子进程 worker 发送图像名。每个 worker 能够通过另一组管道将其结果写回主进程，但这很痛苦，所以每个 worker 都直接写入共享 STDOUT。这工作正常，但正如人们所预料的那样，对 STDOUT 的写入发生冲突，因此各种图像的结果最终会混杂在一起。那很糟糕。我不想自己设置个锁，但幸运的是 GNU libc 为它提供了函数：flockfile()。我把它们放进去了……但是没有用！为什么？因为 flockfile() 最终因为 fork() 的写时复制行为而被限制在单个子进程中。即 fork()提供的额外安全性（与线程相比），这实际上最终破坏了锁。

我没有尝试使用其他锁机制（例如 pthread 互斥锁），但我可以想象它们会遇到类似的问题。我想保持简单，所以将输出发送回父输出是不可能的：这给程序员和运行程序的计算机制造了更多的工作。

解决方案：使用线程而不是 fork()。这有制造冗余管道的好的副作用。最终的伪代码：

for(children)
{
    pthread_create(worker, child_index);
}
for(children)
{
    pthread_join(child);
}

worker(child_index)
{
    for(i_image = child_index; i_image < N_images; i_image += N_children)
    {
        results = process(images[i_image]);
        flockfile(stdout);
        printf(results);
        funlockfile(stdout);
    }
}

这更简单，如预期的那样工作。我猜有时线程更好。

将部分读取的文件传递给子进程

对于各种 vnlog 工具，我需要实现这个操作序列：

1. 进程打开一个关闭 O_CLOEXEC 标志的文件
2. 进程读取此文件的一部分（在 vnlog 的情况下直到图例的末尾）
3. 进程调用 exec() 以调用另一个程序来处理已经打开的文件的其余部分

第二个程序可能需要命令行中的文件名而不是已打开的文件描述符，因为第二个程序可能自己调用 ​​open()。如果我传递文件名，这个新程序将重新打开文件，然后从头开始读取文件，而不是从原始程序停止的位置开始读取。在我的程序上不可以这样做，因此将文件名传递给第二个程序是行不通的。

所以我真的需要以某种方式传递已经打开的文件描述符。我在使用 Linux（其他操作系统可能在这里表现不同），所以我理论上可以通过传递 /dev/fd/N 而不是文件名来实现。但事实证明这也不起作用。在 Linux上（再说一次，也许是特定于 Linux）对于普通文件 /dev/fd/N 是原始文件的符号链接。所以这最终做的是与传递文件名完全相同的事情。

但有一个临时方案！如果我们正在读取管道而不是文件，那么没有什么可以符号链接，并且 /dev/fd/N 最终将原始管道传递给第二个进程，然后程序正常工作。我可以通过将上面的 open("filename") 更改为 popen("cat filename") 之类的东西来伪装。呸！这真的是我们所能做到最好的吗？这在 BSD 上看上去会怎么样？

via: http://notes.secretsauce.net/notes/2018/08/03_unix-curiosities.html

作者：Dima Kogan 选题：lujun9972 译者：geekpi 校对：wxy

本文由 LCTT 原创编译，Linux中国 荣誉推出

在我前面的博客文章 “我的第一个 Go 微服务：使用 MongoDB 和 Docker 多阶段构建” 中，我创建了一个 Go 微服务示例，它发布一个 REST 式的 http 端点，并将从 HTTP POST 中接收到的数据保存到 MongoDB 数据库。

在这个示例中，我将数据的保存和 MongoDB 分离，并创建另一个微服务去处理它。我还添加了 Kafka 为消息层服务，这样微服务就可以异步处理它自己关心的东西了。

如果你有时间去看，我将这个博客文章的整个过程录制到 这个视频中了 :)

下面是这个使用了两个微服务的简单的异步处理示例的上层架构图。

微服务 1 —— 是一个 REST 式微服务，它从一个 /POST http 调用中接收数据。接收到请求之后，它从 http 请求中检索数据，并将它保存到 Kafka。保存之后，它通过 /POST 发送相同的数据去响应调用者。

微服务 2 —— 是一个订阅了 Kafka 中的一个主题的微服务，微服务 1 的数据保存在该主题。一旦消息被微服务消费之后，它接着保存数据到 MongoDB 中。

在你继续之前，我们需要能够去运行这些微服务的几件东西：

1. 下载 Kafka —— 我使用的版本是 kafka\_2.11-1.1.0
2. 安装 librdkafka —— 不幸的是，这个库应该在目标系统中
3. 安装 Kafka Go 客户端
4. 运行 MongoDB。你可以去看我的 以前的文章 中关于这一块的内容，那篇文章中我使用了一个 MongoDB docker 镜像。

我们开始吧！

首先，启动 Kafka，在你运行 Kafka 服务器之前，你需要运行 Zookeeper。下面是示例：

$ cd /<download path>/kafka_2.11-1.1.0
$ bin/zookeeper-server-start.sh config/zookeeper.properties

接着运行 Kafka —— 我使用 9092 端口连接到 Kafka。如果你需要改变端口，只需要在 config/server.properties 中配置即可。如果你像我一样是个新手，我建议你现在还是使用默认端口。

$ bin/kafka-server-start.sh config/server.properties

Kafka 跑起来之后，我们需要 MongoDB。它很简单，只需要使用这个 docker-compose.yml 即可。

version: '3'
services:
  mongodb:
    image: mongo
    ports:
      - "27017:27017"
    volumes:
      - "mongodata:/data/db"
    networks:
      - network1

volumes:
   mongodata:

networks:
   network1:

使用 Docker Compose 去运行 MongoDB docker 容器。

docker-compose up

这里是微服务 1 的相关代码。我只是修改了我前面的示例去保存到 Kafka 而不是 MongoDB：

rest-to-kafka/rest-kafka-sample.go

func jobsPostHandler(w http.ResponseWriter, r *http.Request) {

    //Retrieve body from http request
    b, err := ioutil.ReadAll(r.Body)
    defer r.Body.Close()
    if err != nil {
        panic(err)
    }

    //Save data into Job struct
    var _job Job
    err = json.Unmarshal(b, &_job)
    if err != nil {
        http.Error(w, err.Error(), 500)
        return
    }

    saveJobToKafka(_job)

    //Convert job struct into json
    jsonString, err := json.Marshal(_job)
    if err != nil {
        http.Error(w, err.Error(), 500)
        return
    }

    //Set content-type http header
    w.Header().Set("content-type", "application/json")

    //Send back data as response
    w.Write(jsonString)

}

func saveJobToKafka(job Job) {

    fmt.Println("save to kafka")

    jsonString, err := json.Marshal(job)

    jobString := string(jsonString)
    fmt.Print(jobString)

    p, err := kafka.NewProducer(&kafka.ConfigMap{"bootstrap.servers": "localhost:9092"})
    if err != nil {
        panic(err)
    }

    // Produce messages to topic (asynchronously)
    topic := "jobs-topic1"
    for _, word := range []string{string(jobString)} {
        p.Produce(&kafka.Message{
            TopicPartition: kafka.TopicPartition{Topic: &topic, Partition: kafka.PartitionAny},
            Value:          []byte(word),
        }, nil)
    }
}

这里是微服务 2 的代码。在这个代码中最重要的东西是从 Kafka 中消费数据，保存部分我已经在前面的博客文章中讨论过了。这里代码的重点部分是从 Kafka 中消费数据：

kafka-to-mongo/kafka-mongo-sample.go

func main() {

    //Create MongoDB session
    session := initialiseMongo()
    mongoStore.session = session

    receiveFromKafka()

}

func receiveFromKafka() {

    fmt.Println("Start receiving from Kafka")
    c, err := kafka.NewConsumer(&kafka.ConfigMap{
        "bootstrap.servers": "localhost:9092",
        "group.id":          "group-id-1",
        "auto.offset.reset": "earliest",
    })

    if err != nil {
        panic(err)
    }

    c.SubscribeTopics([]string{"jobs-topic1"}, nil)

    for {
        msg, err := c.ReadMessage(-1)

        if err == nil {
            fmt.Printf("Received from Kafka %s: %s\n", msg.TopicPartition, string(msg.Value))
            job := string(msg.Value)
            saveJobToMongo(job)
        } else {
            fmt.Printf("Consumer error: %v (%v)\n", err, msg)
            break
        }
    }

    c.Close()

}

func saveJobToMongo(jobString string) {

    fmt.Println("Save to MongoDB")
    col := mongoStore.session.DB(database).C(collection)

    //Save data into Job struct
    var _job Job
    b := []byte(jobString)
    err := json.Unmarshal(b, &_job)
    if err != nil {
        panic(err)
    }

    //Insert job into MongoDB
    errMongo := col.Insert(_job)
    if errMongo != nil {
        panic(errMongo)
    }

    fmt.Printf("Saved to MongoDB : %s", jobString)

}

我们来演示一下，运行微服务 1。确保 Kafka 已经运行了。

$ go run rest-kafka-sample.go

我使用 Postman 向微服务 1 发送数据。

这里是日志，你可以在微服务 1 中看到。当你看到这些的时候，说明已经接收到了来自 Postman 发送的数据，并且已经保存到了 Kafka。

因为我们尚未运行微服务 2，数据被微服务 1 只保存在了 Kafka。我们来消费它并通过运行的微服务 2 来将它保存到 MongoDB。

$ go run kafka-mongo-sample.go

现在，你将在微服务 2 上看到消费的数据，并将它保存到了 MongoDB。

检查一下数据是否保存到了 MongoDB。如果有数据，我们成功了！

完整的源代码可以在这里找到：

https://github.com/donvito/learngo/tree/master/rest-kafka-mongo-microservice

现在是广告时间：如果你喜欢这篇文章，请在 Twitter @donvito 上关注我。我的 Twitter 上有关于 Docker、Kubernetes、GoLang、Cloud、DevOps、Agile 和 Startups 的内容。欢迎你们在 GitHub 和 LinkedIn 关注我。

开心地玩吧！

via: https://www.melvinvivas.com/developing-microservices-using-kafka-and-mongodb/

作者：Melvin Vivas 译者：qhwdw 校对：wxy

本文由 LCTT 原创编译，Linux中国 荣誉推出

在软件开发中经常会提到 持续集成 Continuous Integration （CI）和 持续交付 Continuous Delivery （CD）这几个术语。但它们真正的意思是什么呢？

在谈论软件开发时，经常会提到 持续集成 Continuous Integration （CI）和 持续交付 Continuous Delivery （CD）这几个术语。但它们真正的意思是什么呢？在本文中，我将解释这些和相关术语背后的含义和意义，例如 持续测试 Continuous Testing 和 持续部署 Continuous Deployment 。

概览

工厂里的装配线以快速、自动化、可重复的方式从原材料生产出消费品。同样，软件交付管道以快速、自动化和可重复的方式从源代码生成发布版本。如何完成这项工作的总体设计称为“持续交付”（CD）。启动装配线的过程称为“持续集成”（CI）。确保质量的过程称为“持续测试”，将最终产品提供给用户的过程称为“持续部署”。一些专家让这一切简单、顺畅、高效地运行，这些人被称为 运维开发 DevOps 践行者。

“持续”是什么意思？

“持续”用于描述遵循我在此提到的许多不同流程实践。这并不意味着“一直在运行”，而是“随时可运行”。在软件开发领域，它还包括几个核心概念/最佳实践。这些是：

• 频繁发布：持续实践背后的目标是能够频繁地交付高质量的软件。此处的交付频率是可变的，可由开发团队或公司定义。对于某些产品，一季度、一个月、一周或一天交付一次可能已经足够频繁了。对于另一些来说，一天可能需要多次交付也是可行的。所谓持续也有“偶尔、按需”的方面。最终目标是相同的：在可重复、可靠的过程中为最终用户提供高质量的软件更新。通常，这可以通过很少甚至无需用户的交互或掌握的知识来完成（想想设备更新）。
• 自动化流程：实现此频率的关键是用自动化流程来处理软件生产中的方方面面。这包括构建、测试、分析、版本控制，以及在某些情况下的部署。
• 可重复：如果我们使用的自动化流程在给定相同输入的情况下始终具有相同的行为，则这个过程应该是可重复的。也就是说，如果我们把某个历史版本的代码作为输入，我们应该得到对应相同的可交付产出。这也假设我们有相同版本的外部依赖项（即我们不创建该版本代码使用的其它交付物）。理想情况下，这也意味着可以对管道中的流程进行版本控制和重建（请参阅稍后的 DevOps 讨论）。
• 快速迭代：“快速”在这里是个相对术语，但无论软件更新/发布的频率如何，预期的持续过程都会以高效的方式将源代码转换为交付物。自动化负责大部分工作，但自动化处理的过程可能仍然很慢。例如，对于每天需要多次发布候选版更新的产品来说，一轮 集成测试 integrated testing 下来耗时就要大半天可能就太慢了。

什么是“持续交付管道”？

将源代码转换为可发布产品的多个不同的 任务 task 和 作业 job 通常串联成一个软件“管道”，一个自动流程成功完成后会启动管道中的下一个流程。这些管道有许多不同的叫法，例如持续交付管道、部署管道和软件开发管道。大体上讲，程序管理者在管道执行时管理管道各部分的定义、运行、监控和报告。

持续交付管道是如何工作的？

软件交付管道的实际实现可以有很大不同。有许多程序可用在管道中，用于源代码跟踪、构建、测试、指标采集，版本管理等各个方面。但整体工作流程通常是相同的。单个业务流程/工作流应用程序管理整个管道，每个流程作为独立的作业运行或由该应用程序进行阶段管理。通常，在业务流程中，这些独立作业是以应用程序可理解并可作为工作流程管理的语法和结构定义的。

这些作业被用于一个或多个功能（构建、测试、部署等）。每个作业可能使用不同的技术或多种技术。关键是作业是自动化的、高效的，并且可重复的。如果作业成功，则工作流管理器将触发管道中的下一个作业。如果作业失败，工作流管理器会向开发人员、测试人员和其他人发出警报，以便他们尽快纠正问题。这个过程是自动化的，所以比手动运行一组过程可更快地找到错误。这种快速排错称为 快速失败 fail fast ，并且在抵达管道端点方面同样有价值。

“快速失败”是什么意思？

管道的工作之一就是快速处理变更。另一个是监视创建发布的不同任务/作业。由于编译失败或测试未通过的代码可以阻止管道继续运行，因此快速通知用户此类情况非常重要。快速失败指的是在管道流程中尽快发现问题并快速通知用户的方式，这样可以及时修正问题并重新提交代码以便使管道再次运行。通常在管道流程中可通过查看历史记录来确定是谁做了那次修改并通知此人及其团队。

所有持续交付管道都应该被自动化吗？

管道的几乎所有部分都是应该自动化的。对于某些部分，有一些人为干预/互动的地方可能是有意义的。一个例子可能是 用户验收测试 user-acceptance testing （让最终用户试用软件并确保它能达到他们想要/期望的水平）。另一种情况可能是部署到生产环境时用户希望拥有更多的人为控制。当然，如果代码不正确或不能运行，则需要人工干预。

有了对“持续”含义理解的背景，让我们看看不同类型的持续流程以及它们在软件管道上下文中的含义。

什么是“持续集成”？

持续集成（CI）是在源代码变更后自动检测、拉取、构建和（在大多数情况下）进行单元测试的过程。持续集成是启动管道的环节（尽管某些预验证 —— 通常称为 上线前检查 pre-flight checks —— 有时会被归在持续集成之前）。

持续集成的目标是快速确保开发人员新提交的变更是好的，并且适合在代码库中进一步使用。

持续集成是如何工作的？

持续集成的基本思想是让一个自动化过程监测一个或多个源代码仓库是否有变更。当变更被推送到仓库时，它会监测到更改、下载副本、构建并运行任何相关的单元测试。

持续集成如何监测变更？

目前，监测程序通常是像 Jenkins 这样的应用程序，它还协调管道中运行的所有（或大多数）进程，监视变更是其功能之一。监测程序可以以几种不同方式监测变更。这些包括：

• 轮询：监测程序反复询问代码管理系统，“代码仓库里有什么我感兴趣的新东西吗？”当代码管理系统有新的变更时，监测程序会“唤醒”并完成其工作以获取新代码并构建/测试它。
• 定期：监测程序配置为定期启动构建，无论源码是否有变更。理想情况下，如果没有变更，则不会构建任何新内容，因此这不会增加额外的成本。
• 推送：这与用于代码管理系统检查的监测程序相反。在这种情况下，代码管理系统被配置为提交变更到仓库时将“推送”一个通知到监测程序。最常见的是，这可以以 webhook 的形式完成 —— 在新代码被推送时一个 挂勾 hook 的程序通过互联网向监测程序发送通知。为此，监测程序必须具有可以通过网络接收 webhook 信息的开放端口。

什么是“预检查”（又称“上线前检查”）？

在将代码引入仓库并触发持续集成之前，可以进行其它验证。这遵循了最佳实践，例如 测试构建 test build 和 代码审查 code review 。它们通常在代码引入管道之前构建到开发过程中。但是一些管道也可能将它们作为其监控流程或工作流的一部分。

例如，一个名为 Gerrit 的工具允许在开发人员推送代码之后但在允许进入（Git 远程）仓库之前进行正式的代码审查、验证和测试构建。Gerrit 位于开发人员的工作区和 Git 远程仓库之间。它会“接收”来自开发人员的推送，并且可以执行通过/失败验证以确保它们在被允许进入仓库之前的检查是通过的。这可以包括检测新变更并启动构建测试（CI 的一种形式）。它还允许开发者在那时进行正式的代码审查。这种方式有一种额外的可信度评估机制，即当变更的代码被合并到代码库中时不会破坏任何内容。

什么是“单元测试”？

单元测试（也称为“提交测试”），是由开发人员编写的小型的专项测试，以确保新代码独立工作。“独立”这里意味着不依赖或调用其它不可直接访问的代码，也不依赖外部数据源或其它模块。如果运行代码需要这样的依赖关系，那么这些资源可以用 模拟 mock 来表示。模拟是指使用看起来像资源的 代码存根 code stub ，可以返回值，但不实现任何功能。

在大多数组织中，开发人员负责创建单元测试以证明其代码正确。事实上，一种称为 测试驱动开发 test-driven develop （TDD）的模型要求将首先设计单元测试作为清楚地验证代码功能的基础。因为这样的代码可以更改速度快且改动量大，所以它们也必须执行很快。

由于这与持续集成工作流有关，因此开发人员在本地工作环境中编写或更新代码，并通单元测试来确保新开发的功能或方法正确。通常，这些测试采用断言形式，即函数或方法的给定输入集产生给定的输出集。它们通常进行测试以确保正确标记和处理出错条件。有很多单元测试框架都很有用，例如用于 Java 开发的 JUnit。

什么是“持续测试”？

持续测试是指在代码通过持续交付管道时运行扩展范围的自动化测试的实践。单元测试通常与构建过程集成，作为持续集成阶段的一部分，并专注于和其它与之交互的代码隔离的测试。

除此之外，可以有或者应该有各种形式的测试。这些可包括：

• 集成测试 验证组件和服务组合在一起是否正常。
• 功能测试 验证产品中执行功能的结果是否符合预期。
• 验收测试 根据可接受的标准验证产品的某些特征。如性能、可伸缩性、抗压能力和容量。

所有这些可能不存在于自动化的管道中，并且一些不同类型的测试分类界限也不是很清晰。但是，在交付管道中持续测试的目标始终是相同的：通过持续的测试级别证明代码的质量可以在正在进行的发布中使用。在持续集成快速的原则基础上，第二个目标是快速发现问题并提醒开发团队。这通常被称为快速失败。

除了测试之外，还可以对管道中的代码进行哪些其它类型的验证？

除了测试是否通过之外，还有一些应用程序可以告诉我们测试用例执行（覆盖）的源代码行数。这是一个可以衡量代码量指标的例子。这个指标称为 代码覆盖率 code-coverage ，可以通过工具（例如用于 Java 的 JaCoCo）进行统计。

还有很多其它类型的指标统计，例如代码行数、复杂度以及代码结构对比分析等。诸如 SonarQube 之类的工具可以检查源代码并计算这些指标。此外，用户还可以为他们可接受的“合格”范围的指标设置阈值。然后可以在管道中针对这些阈值设置一个检查，如果结果不在可接受范围内，则流程终端上。SonarQube 等应用程序具有很高的可配置性，可以设置仅检查团队感兴趣的内容。

什么是“持续交付”？

持续交付（CD）通常是指整个流程链（管道），它自动监测源代码变更并通过构建、测试、打包和相关操作运行它们以生成可部署的版本，基本上没有任何人为干预。

持续交付在软件开发过程中的目标是自动化、效率、可靠性、可重复性和质量保障（通过持续测试）。

持续交付包含持续集成（自动检测源代码变更、执行构建过程、运行单元测试以验证变更），持续测试（对代码运行各种测试以保障代码质量），和（可选）持续部署（通过管道发布版本自动提供给用户）。

如何在管道中识别/跟踪多个版本？

版本控制是持续交付和管道的关键概念。持续意味着能够经常集成新代码并提供更新版本。但这并不意味着每个人都想要“最新、最好的”。对于想要开发或测试已知的稳定版本的内部团队来说尤其如此。因此，管道创建并轻松存储和访问的这些版本化对象非常重要。

在管道中从源代码创建的对象通常可以称为 工件 artifact 。工件在构建时应该有应用于它们的版本。将版本号分配给工件的推荐策略称为 语义化版本控制 semantic versioning 。（这也适用于从外部源引入的依赖工件的版本。）

语义版本号有三个部分： 主要版本 major 、 次要版本 minor 和 补丁版本 patch 。（例如，1.4.3 反映了主要版本 1，次要版本 4 和补丁版本 3。）这个想法是，其中一个部分的更改表示工件中的更新级别。主要版本仅针对不兼容的 API 更改而递增。当以 向后兼容 backward-compatible 的方式添加功能时，次要版本会增加。当进行向后兼容的版本 bug 修复时，补丁版本会增加。这些是建议的指导方针，但只要团队在整个组织内以一致且易于理解的方式这样做，团队就可以自由地改变这种方法。例如，每次为发布完成构建时增加的数字可以放在补丁字段中。

如何“分销”工件？

团队可以为工件分配 分销 promotion 级别以指示适用于测试、生产等环境或用途。有很多方法。可以用 Jenkins 或 Artifactory 等应用程序进行分销。或者一个简单的方案可以在版本号字符串的末尾添加标签。例如，-snapshot 可以指示用于构建工件的代码的最新版本（快照）。可以使用各种分销策略或工具将工件“提升”到其它级别，例如 -milestone 或 -production，作为工件稳定性和完备性版本的标记。

如何存储和访问多个工件版本？

从源代码构建的版本化工件可以通过管理 工件仓库 artifact repository 的应用程序进行存储。工件仓库就像构建工件的版本控制工具一样。像 Artifactory 或 Nexus 这类应用可以接受版本化工件，存储和跟踪它们，并提供检索的方法。

管道用户可以指定他们想要使用的版本，并在这些版本中使用管道。

什么是“持续部署”？

持续部署（CD）是指能够自动提供持续交付管道中发布版本给最终用户使用的想法。根据用户的安装方式，可能是在云环境中自动部署、app 升级（如手机上的应用程序）、更新网站或只更新可用版本列表。

这里的一个重点是，仅仅因为可以进行持续部署并不意味着始终部署来自管道的每组可交付成果。它实际上指，通过管道每套可交付成果都被证明是“可部署的”。这在很大程度上是由持续测试的连续级别完成的（参见本文中的持续测试部分）。

管道构建的发布成果是否被部署可以通过人工决策，或利用在完全部署之前“试用”发布的各种方法来进行控制。

在完全部署到所有用户之前，有哪些方法可以测试部署？

由于必须回滚/撤消对所有用户的部署可能是一种代价高昂的情况（无论是技术上还是用户的感知），已经有许多技术允许“尝试”部署新功能并在发现问题时轻松“撤消”它们。这些包括：

蓝/绿测试/部署

在这种部署软件的方法中，维护了两个相同的主机环境 —— 一个“蓝色” 和一个“绿色”。（颜色并不重要，仅作为标识。）对应来说，其中一个是“生产环境”，另一个是“预发布环境”。

在这些实例的前面是调度系统，它们充当产品或应用程序的客户“网关”。通过将调度系统指向蓝色或绿色实例，可以将客户流量引流到期望的部署环境。通过这种方式，切换指向哪个部署实例（蓝色或绿色）对用户来说是快速，简单和透明的。

当新版本准备好进行测试时，可以将其部署到非生产环境中。在经过测试和批准后，可以更改调度系统设置以将传入的线上流量指向它（因此它将成为新的生产站点）。现在，曾作为生产环境实例可供下一次候选发布使用。

同理，如果在最新部署中发现问题并且之前的生产实例仍然可用，则简单的更改可以将客户流量引流回到之前的生产实例 —— 有效地将问题实例“下线”并且回滚到以前的版本。然后有问题的新实例可以在其它区域中修复。

金丝雀测试/部署

在某些情况下，通过蓝/绿发布切换整个部署可能不可行或不是期望的那样。另一种方法是为 金丝雀 canary 测试/部署。在这种模型中，一部分客户流量被重新引流到新的版本部署中。例如，新版本的搜索服务可以与当前服务的生产版本一起部署。然后，可以将 10％ 的搜索查询引流到新版本，以在生产环境中对其进行测试。

如果服务那些流量的新版本没问题，那么可能会有更多的流量会被逐渐引流过去。如果仍然没有问题出现，那么随着时间的推移，可以对新版本增量部署，直到 100％ 的流量都调度到新版本。这有效地“更替”了以前版本的服务，并让新版本对所有客户生效。

功能开关

对于可能需要轻松关掉的新功能（如果发现问题），开发人员可以添加 功能开关 feature toggles 。这是代码中的 if-then 软件功能开关，仅在设置数据值时才激活新代码。此数据值可以是全局可访问的位置，部署的应用程序将检查该位置是否应执行新代码。如果设置了数据值，则执行代码；如果没有，则不执行。

这为开发人员提供了一个远程“终止开关”，以便在部署到生产环境后发现问题时关闭新功能。

暗箱发布

在 暗箱发布 dark launch 中，代码被逐步测试/部署到生产环境中，但是用户不会看到更改（因此名称中有 暗箱 dark 一词）。例如，在生产版本中，网页查询的某些部分可能会重定向到查询新数据源的服务。开发人员可收集此信息进行分析，而不会将有关接口，事务或结果的任何信息暴露给用户。

这个想法是想获取候选版本在生产环境负载下如何执行的真实信息，而不会影响用户或改变他们的经验。随着时间的推移，可以调度更多负载，直到遇到问题或认为新功能已准备好供所有人使用。实际上功能开关标志可用于这种暗箱发布机制。

什么是“运维开发”？

运维开发 DevOps 是关于如何使开发和运维团队更容易合作开发和发布软件的一系列想法和推荐的实践。从历史上看，开发团队研发了产品，但没有像客户那样以常规、可重复的方式安装/部署它们。在整个周期中，这组安装/部署任务（以及其它支持任务）留给运维团队负责。这经常导致很多混乱和问题，因为运维团队在后期才开始介入，并且必须在短时间内完成他们的工作。同样，开发团队经常处于不利地位 —— 因为他们没有充分测试产品的安装/部署功能，他们可能会对该过程中出现的问题感到惊讶。

这往往导致开发和运维团队之间严重脱节和缺乏合作。DevOps 理念主张是贯穿整个开发周期的开发和运维综合协作的工作方式，就像持续交付那样。

持续交付如何与运维开发相交？

持续交付管道是几个 DevOps 理念的实现。产品开发的后期阶段（如打包和部署）始终可以在管道的每次运行中完成，而不是等待产品开发周期中的特定时间。同样，从开发到部署过程中，开发和运维都可以清楚地看到事情何时起作用，何时不起作用。要使持续交付管道循环成功，不仅要通过与开发相关的流程，还要通过与运维相关的流程。

说得更远一些，DevOps 建议实现管道的基础架构也会被视为代码。也就是说，它应该自动配置、可跟踪、易于修改，并在管道发生变化时触发新一轮运行。这可以通过将管道实现为代码来完成。

什么是“管道即代码”？

管道即代码 pipeline-as-code 是通过编写代码创建管道作业/任务的通用术语，就像开发人员编写代码一样。它的目标是将管道实现表示为代码，以便它可以与代码一起存储、评审、跟踪，如果出现问题并且必须终止管道，则可以轻松地重建。有几个工具允许这样做，如 Jenkins 2。

DevOps 如何影响生产软件的基础设施？

传统意义上，管道中使用的各个硬件系统都有配套的软件（操作系统、应用程序、开发工具等）。在极端情况下，每个系统都是手工设置来定制的。这意味着当系统出现问题或需要更新时，这通常也是一项自定义任务。这种方法违背了持续交付的基本理念，即具有易于重现和可跟踪的环境。

多年来，很多应用被开发用于标准化交付（安装和配置）系统。同样， 虚拟机 virtual machine 被开发为模拟在其它计算机之上运行的计算机程序。这些 VM 要有管理程序才能在底层主机系统上运行，并且它们需要自己的操作系统副本才能运行。

后来有了 容器 container 。容器虽然在概念上与 VM 类似，但工作方式不同。它们只需使用一些现有的操作系统结构来划分隔离空间，而不需要运行单独的程序和操作系统的副本。因此，它们的行为类似于 VM 以提供隔离但不需要过多的开销。

VM 和容器是根据配置定义创建的，因此可以轻易地销毁和重建，而不会影响运行它们的主机系统。这允许运行管道的系统也可重建。此外，对于容器，我们可以跟踪其构建定义文件的更改 —— 就像对源代码一样。

因此，如果遇到 VM 或容器中的问题，我们可以更容易、更快速地销毁和重建它们，而不是在当前环境尝试调试和修复。

这也意味着对管道代码的任何更改都可以触发管道新一轮运行（通过 CI），就像对代码的更改一样。这是 DevOps 关于基础架构的核心理念之一。

via: https://opensource.com/article/18/8/what-cicd

作者：Brent Laster 选题：lujun9972 译者：pityonline 校对：wxy

本文由 LCTT 原创编译，Linux中国 荣誉推出

前略：Yaourt 曾是最流行的 AUR 助手，但现已停止开发。在这篇文章中，我们会为 Arch 衍生发行版们列出 Yaourt 最佳的替代品。

Arch User Repository （常被称作 AUR），是一个为 Arch 用户而生的社区驱动软件仓库。Debian/Ubuntu 用户的对应类比是 PPA。

AUR 包含了不直接被 Arch Linux 官方所背书的软件。如果有人想在 Arch 上发布软件或者包，它可以通过这个社区仓库提供。这让最终用户们可以使用到比默认仓库里更多的软件。

所以你该如何使用 AUR 呢？简单来说，你需要另外的工具以从 AUR 中安装软件。Arch 的包管理器 pacman 不直接支持 AUR。那些支持 AUR 的“特殊工具”我们称之为 AUR 助手。

Yaourt （Yet AnOther User Repository Tool）（曾经）是 pacman 的一个封装，便于用户在 Arch Linux 上安装 AUR 软件。它基本上采用和 pacman 一样的语法。Yaourt 对于 AUR 的搜索、安装，乃至冲突解决和包依赖关系维护都有着良好的支持。

然而，Yaourt 的开发进度近来十分缓慢，甚至在 Arch Wiki 上已经被列为“停止或有问题”。许多 Arch 用户认为它不安全 进而开始寻找其它的 AUR 助手。

在这篇文章中，我们会介绍 Yaourt 最佳的替代品以便于你从 AUR 安装软件。

最好的 AUR 助手

我刻意忽略掉了例如 Trizen 和 Packer 这样的流行的选择，因为它们也被列为“停止或有问题”的了。

1、 aurman

aurman 是最好的 AUR 助手之一，也能胜任 Yaourt 替代品的地位。它有非常类似于 pacman 的语法，可以支持所有的 pacman 操作。你可以搜索 AUR、解决包依赖，在构建 AUR 包前检查 PKGBUILD 的内容等等。

aurman 的特性：

• aurman 支持所有 pacman 操作，并且引入了可靠的包依赖解决方案、冲突判定和 分包 split package 支持
• 线程化的 sudo 循环会在后台运行，所以你每次安装只需要输入一次管理员密码
• 提供开发包支持，并且可以区分显性安装和隐性安装的包
• 支持搜索 AUR 包和仓库
• 在构建 AUR 包之前，你可以检视并编辑 PKGBUILD 的内容
• 可以用作单独的 包依赖解决工具

安装 aurman：

git clone https://aur.archlinux.org/aurman.git
cd aurman
makepkg -si

使用 aurman：

用名字搜索：

aurman -Ss <package-name>

安装：

aurman -S <package-name>

2、 yay

yay 是下一个最好的 AUR 助手。它使用 Go 语言写成，宗旨是提供最少化用户输入的 pacman 界面、yaourt 式的搜索，而几乎没有任何依赖软件。

yay 的特性：

• yay 提供 AUR 表格补全，并且从 ABS 或 AUR 下载 PKGBUILD
• 支持收窄搜索，并且不需要引用 PKGBUILD 源
• yay 的二进制文件除了 pacman 以外别无依赖
• 提供先进的包依赖解决方案，以及在编译安装之后移除编译时的依赖
• 当在 /etc/pacman.conf 文件配置中启用了色彩时支持色彩输出
• yay 可被配置成只支持 AUR 或者 repo 里的软件包

安装 yay：

你可以从 git 克隆并编译安装。

git clone https://aur.archlinux.org/yay.git
cd yay
makepkg -si

使用 yay：

搜索：

yay -Ss <package-name>

安装：

yay -S <package-name>

3、 pakku

Pakku 是另一个还处于开发早期的 pacman 封装，虽然它还处于开放早期，但这不说明它逊于其它任何 AUR 助手。Pakku 能很好地支持从 AUR 搜索和安装，并且也可以在安装后移除不必要的编译依赖。

pakku 的特性：

• 从 AUR 搜索和安装软件
• 检视不同构建之间的文件和变化
• 从官方仓库编译，并事后移除编译依赖
• 获取 PKGBUILD 以及 pacman 整合
• 类 pacman 的用户界面和选项支持
• 支持pacman 配置文件以及无需 PKGBUILD 源

安装 pakku：

git clone https://aur.archlinux.org/pakku.git
cd pakku
makepkg -si

使用 pakku：

搜索：

pakku -Ss spotify

安装：

pakku -S spotify

4、 aurutils

aurutils 本质上是一堆使用 AUR 的自动化脚本的集合。它可以搜索 AUR、检查更新，并且解决包依赖。

aurutils 的特性：

• aurutils 使用本地仓库以支持 pacman 文件，所有的包都支持 –asdeps
• 不同的任务可以有多个仓库
• aursync -u 一键同步本地代码库
• aursearch 搜索提供 pkgbase、长格式和 raw 支持
• 能忽略指定包

安装 aurutils：

git clone https://aur.archlinux.org/aurutils.git
cd aurutils
makepkg -si

使用 aurutils：

搜索：

aurutils -Ss <package-name>

安装：

aurutils -S <package-name>

所有这些包，在有 Yaourt 或者其它 AUR 助手的情况下都可以直接安装。

写在最后

Arch Linux 有着很多 AUR 助手 可以自动完成 AUR 各方面的日常任务。很多用户依然使用 Yaourt 来完成 AUR 相关任务，每个人都有自己不一样的偏好，欢迎留言告诉我们你在 Arch 里使用什么，又有什么心得？

via: https://itsfoss.com/best-aur-helpers/

作者：Ambarish Kumar 选题：lujun9972 译者：Moelf 校对：wxy

本文由 LCTT 原创编译，Linux中国 荣誉推出

在 Linux 上处理音频是一件很痛苦的事情。Pulseaudio 的出现则是利弊参半。虽然有些事情 Pluseaudio 能够做的更好，但有些事情则反而变得更复杂了。处理音频的输出就是这么一件事情。

如果你想要在 Linux PC 上启用多个音频输出，你只需要利用一个简单的工具就能在一个虚拟j接口上启用另一个声音设备。这比看起来要简单的多。

你可能会好奇为什么要这么做，一个很常见的情况是用电脑在电视上播放视频，你可以同时使用电脑和电视上的扬声器。

安装 Paprefs

实现从多个来源启用音频播放的最简单的方法是是一款名为 “paprefs” 的简单图形化工具。它是 PulseAudio Preferences 的缩写。

该软件包含在 Ubuntu 仓库中，可以直接用 apt 来进行安装。

sudo apt install paprefs

安装后就能够启动这款程序了。

启动双音频播放

虽然这款工具是图形化的，但作为普通用户在命令行中输入 paprefs 来启动它恐怕还是要更容易一些。

打开的窗口中有一些标签页，这些标签页内有一些可以调整的设置项。我们这里选择最后那个标签页，“Simultaneous Output。”

这个标签页中没有什么内容，只是一个复选框用来启用该设置。

下一步，打开常规的声音首选项。这在不同的发行版中位于不同的位置。在 Ubuntu 上，它位于 GNOME 系统设置内。

打开声音首选项后，选择 “output” 标签页。勾选 “Simultaneous output” 单选按钮。现在它就成了你的默认输出了。

测试一下

用什么东西进行测试随你喜欢，不过播放音乐总是可行的。如果你像前面建议的一样，用视频来进行测试也没问题。

一切顺利的话，你就能从所有连接的设备中听到有声音传出了。

这就是所有要做的事了。此功能最适用于有多个设备（如 HDMI 端口和标准模拟输出）时。你当然也可以试一下其他配置。你还需要注意，只有一个音量控制器，因此你需要根据实际情况调整物理输出设备。

via: https://www.maketecheasier.com/play-sound-through-multiple-devices-linux/

作者：Nick Congleton 译者：lujun9972 校对：wxy

本文由 LCTT 原创编译，Linux中国 荣誉推出