大家好，我是QA seven 目前在极狐gitlab 担任测试专家，在极狐一年里，习惯了远程的工作习惯，也对极狐gilab这个产品也有了更深理解，gitlab不仅仅是一个代码管理以及ci/cd工具，它更多带个一个公司是对devops体系的改变，让混乱无章devops工作形成了体系化与平台化，确实有很多优秀开源工具比如Jenkins等也能够实现gitlab的部分功能，但就像ios和android一样，gitlab带给我们是公司devops整体的提升与质的飞跃。
接下来我会将我所学和感悟以及结合国外devops大神的gitlab书籍，汇总写成系列文章。
第一篇 理解devops。
为了欣赏GitLab CI/CD pipeline和DevOps软件开发方法的强大之处，我们必须了解在GitLab等工具出现之前的软件构建方式是如何的。尽管在本章中您不会学到任何实际的技能，但您将了解GitLab CI/CD pipeline 所应对的问题以及它们的发展背景。对于这些内容的掌握将帮助您理解GitLab CI/CD pipeline为何以其特定方式运作，并为您揭示它们为软件开发生命周期带来的巨大威力。简而言之，了解过去的历史是理解现在状况的最佳途径，因为这样可以让您了解曾经的开发困境有多糟糕！
本章将向您介绍一个虚构的但又贴近实际的网络应用程序，名为"Hats for Cats+"，通过介绍将Hats for Cats如何从一个想法转变为编写良好、经过测试和部署的网络应用程序的所涉及的所有步骤，您将快速了解整个过程。您将了解在没有GitLab CI/CD pipeline的情况下，这些任务将会多么困难完成，以及如何执行，以便在后续章节中学习GitLab时，能够有更加明显和直观的对比。
在了解先前的开发环境中的限制和挑战后，您将更好地理解GitLab CI/CD pipeline为现代软件开发带来的益处和功能。这些知识将对您在随后的章节中深入学习GitLab CI/CD pipeline的特点和功能时非常有用。
在本章中，我们将介绍以下主要内容：
• 介绍Hats for Cats网络应用程序
• 手动构建和验证代码
• 手动进行安全测试的代码
• 手动打包和部署代码
• 手动软件开发生命周期实践的问题
• 用DevOps解决问题
Hats for Cats网络应用程序简介
Hats for Cats是一个虚构的网络应用程序，用于销售棒球帽、牛仔帽和圆顶帽。想象一下它是一个非常标准的在线商城，类似京东，甚至功能更为简单，就像您已经使用过的数百或数千个商店一样。它允许用户浏览帽子目录，把商品放入购物车，并输入账单和送货信息。
对于本书来说，Hats for Cats的用户体验或图形设计并不重要。以及它所使用框架和架构也不重要。甚至编写它的计算机语言也不重要。我再次强调这一点，因为这是一个重要观点：本书是与编程语言无关的。但它将包括几种计算机语言的示例，以增加至少有些示例是您熟悉的语言的可能性。但无论您的应用程序 - 还是Hats for Cats网络应用程序 - 是用Java、JavaScript、Python、Ruby还是其他任何语言编写的，都不重要。本书描述的GitLab CI/CD的基本原则适用于所有情况。
真正重要的是您需要了解开发过程中采取的每一个步骤，以确保高质量代码、正确业务行为、服务安全、良好的性能、编译以及打包的正确性，以及在在正确的时间部署到对的环境中。本书侧重于介绍GitLab CI/CD pipeline 如何使整个开发流程在软件开发生命周期(SDLC)中的各个步骤更加简单、快速和可靠。这系列文章不会向您展示如何编写Hats for Cats 应用程序。我们假设所有的编码都是在幕后进行的，之后您将学习如何构建、验证、编译、打包和发布该项目代码。
有了这个想法，让我们回到在GitLab出现之前，我们需要了解并遵循的哪些步骤，以便能够给用户提供正确的代码。而这些都将是手动执行的步骤，而GitLab CI/CD pipeline则可以帮我们自动完成这些步骤。但是了解手动操作流程的局限性以及遵循这些步骤时所涉及的痛苦和乏味将帮助我们更好的理解GitLab的真正威力。
构建和验证代码在GitLab CI/CD pipeline出现之前是需要手动进行构建和验证代码的。这个过程往往是让开发人员有着糟糕的、令人沮丧的经历，我们将也将在这里讨论其中的原因。
手动构建代码构建代码取决于您所使用的编程语言。如果您使用的是解释型语言，比如Python或Ruby，那么可能根本不需要进行构建。但是如果您使用的是编译型语言，就需要通过编译源代码来构建应用程序。
假设您正在使用Java。下面只是编译Java源代码为可执行Java类的几种不同方法之一：
- 您可以使用随Java开发工具包一起提供的javac Java编译器。
- 您可以使用Maven构建工具。
- 您可以使用Gradle构建工具。
以下是手动构建过程是一项乏味、恼人的任务的许多原因：
- 容易出错：您有多少次忘记了是否需要将javac指向您的类所在的顶级包还是个别的类文件？
- 很慢，需要几秒钟到几分钟不等，这取决于您的应用程序的大小。这可能会导致很长的停机时间。
- 很容易忘记构建，当您意外执行旧的代码时，它将导致混乱，因为它的行为与您预期的不同。
- 编写糟糕的代码可能无法编译，导致每个人都会浪费时间，构建工程师不得不将代码回退给开发人员进行修复，并等待修复程序发布。
图1.1 - 验证代码的测试
手动验证代码
一旦完成构建代码，就需要验证其是否正常工作。测试有无数种形式和方法，比我们在这系列文章中描述的更多。下面列出的是我们对代码进行的一些最常见形式的测试：
功能测试 你的程序是否按预期执行？
这就是功能测试要回答的问题。大多数编程项目都从描述软件应如何行为的规范开始：
针对特定的输入，它应该提供什么输出？
只有当开发人员编写的代码符合这些规范时，他们的工作才算完成。
那么他们如何知道自己的代码是否符合规范？ 这就是功能测试的作用。就像一般的测试有许多形式一样，功能测试由许多子类别组成。
happy path测试确保当给予常见、有效的输入时，程序按预期工作。例如，如果你在计算器中输入2 + 2，它应该返回4！happy path测试似乎是最重要的测试类型，因为它们检查用户在使用软件时最有可能遇到的行为。但实际上，您通常可以通过只进行几个happy path测试来涵盖最常见的用例。覆盖异常或意外情况的测试通常要更多。
说到异常情况，大部分情况指的是边界值测试。
想象一下测试输入值范围的场景，用户输入的大多数值将位于该范围的中间。例如，计算器用户更有可能输入56 ÷ 209（其中这些值在计算器接受的值范围的中间）而不是输入0 + 0或999,999 - 999,999（因为这些值位于范围的边缘）。边界情况测试确保超出可接受范围的边缘处的输入值不会破坏您的软件。您能创建只由一个字母组成的用户名吗？您能订购9,999本书吗？您能将1分钱存入银行账户吗？如果规范中要求您的软件应该能够处理这些边界情况，那么您最好确保它确实可以！
如果边界情况测试确保您的软件能够处理边缘输入值，边界测试可以确认您的软件能够处理两个或多个同时发生的边界情况。例如，您的银行应用程序是否允许您在最远的有效日期上安排以最小有效货币金额的提款？限制为两个输入值：如果您的软件一次接受三个、十个或100个输入值，您需要确保当每个输入值在有效值范围定义的极限时，它仍然可以正常工作。
我们还需要确保在接收无效值时它是否能够正确行为吗？当然需要！这种形式的测试有时被称为corner path测试，对于测试人员来说通常更有趣，因为它更有可能揭示错误。所有软件都必须优雅地处理意外、无效或格式错误的数据，您需要测试来证明它能够这样做。回到我们前面的例子，您需要确保计算器在试图将一个数除以零时不会崩溃。您必须检查银行应用程序是否会在您要求提款负6美元时意外给您一笔存款。而且当您询问2020年2月31日的汇率时，您的货币转换软件应该给出一个合理的错误消息。
大部分情况下进入应用程序的脏数据通常比正确的数据要多，开发人员经常集中在正确处理预期数据上，但未能考虑到用户可能输入的异常、格式错误或超出范围的数据类型。程序需要预测并优雅地处理各种数据 - 无论是正确的数据还是坏数据。编写完整的happy path和 corner path测试能够确保开发人员的代码,无论用户输入什么数据都能正常运行的最佳方式。
今天到此为止，明天继续，分享。今天主要带大家了解Automating DevOps with GitLab CI_CD Pipelines第一章里的一些内容。
