skysat重访周期_重访持续部署

skysat重访周期

In an earlier article I talked about what Continuous Deployment was and how it fits into the modern programming process. We took a small swipe at how it works, but some people (okay, one person) felt that I could have gone into more detail and they were right. So, here’s a more detailed description of how Continuous Deployment works in the trenches and how it can change your life.

在较早的文章中，我谈到了什么是持续部署，以及它如何适合现代编程过程。 我们略微了解了它的工作原理，但是有些人(好的，一个人)觉得我本可以更详细地讲，他们是对的。 因此，这是有关持续部署如何在战es中工作以及如何改变您的生活的更详细的描述。

The essence of Continuous Deployment is that you use automated tools to do a lot of the heavy lifting. This means there may or may not be a bit of a learning curve when you first get started. A number of software elements are brought into play, and if you already know how to use those, great. If you don’t, just remember that this is a learning curve, not a barrier.

连续部署的本质是您使用自动化工具来完成许多繁重的工作。 这意味着您一开始就可能没有学习曲线。 许多软件元素都可以发挥作用，如果您已经知道如何使用它们，那就太好了。 如果没有，请记住，这是学习曲线，不是障碍。

版本控制 (Version Control)

The first thing you want to do is establish a baseline system, generally through the use of version control. With the Continuous Deployment process generating new releases of the software every day or so, having a common updated version that people can test against is crucial. You could keep track of your code revisions yourself, just as you could build your own automobile, but most people opt for a version (or revision) control system. Everyone has their particular favorite, although it seems Git is the most popular right now.

您要做的第一件事通常是通过使用版本控制来建立基准系统。 随着持续部署过程每天左右生成新版本的软件，拥有可供人们测试的通用更新版本至关重要。 您可以自己跟踪代码修订，就像可以制造自己的汽车一样，但是大多数人都选择版本(或修订)控制系统。 每个人都有其特别的喜爱，尽管Git似乎是当前最受欢迎的。

I won’t get into Git here, but there are close to a dozen articles already on SitePoint such as Mark Cippola’s Git: A Designers Primer and Sean Hudgston’s opus Introduction to Git. Oh, I almost forgot Jess Genevieve Brown’s Getting Started with Git. I like to highlight authors who use their middle name. I always wonder what would have happened if Willa Cather hadn’t dropped her middle name, Yvette, just before publishing O Pioneers!.

我不会在这里介绍Git，但是SitePoint上已经有近十二篇文章，例如Mark Cippola的Git：设计师入门入门和Sean Hudgston的作品《 Git简介》 。 哦，我差点忘了杰西·吉恩维芙·布朗的《 Git入门》 。 我想强调使用中间名的作者。 我总是想知道如果Willa Cather在出版《 O Pioneers》之前没有放弃她的中间名Yvette，将会发生什么！ 。

Naturally, you will also need an environment, a clone of the production system, in which the application can be run and tested. Most of us probably already have a solid test system, but if you don’t then you need one.

自然，您还将需要一个环境，即生产系统的克隆，可以在其中运行和测试应用程序。 我们大多数人可能已经拥有一个可靠的测试系统，但是如果您没有，那么您需要一个。

The bottom line is: get a version control system and find a way to define a baseline system. This will change with every Continuous Deployment update, but you need one system that everyone can agree is the gold standard.

最重要的是：获得一个版本控制系统，并找到一种定义基线系统的方法。 每次“持续部署”更新都会改变这种情况，但是您需要一个每个人都可以接受的黄金标准系统。

致力于自动化测试 (Commit to Automated Testing)

The next thing you need is the ability to do some major league testing. The essence of Continuous Deployment is to have updates to your code occur all the time, not just at the end of a quarter. But another aspect is to produce not just code, but good code, essentially bug free code. And to do that, you need to test.

接下来，您需要做一些大联盟测试的能力。 持续部署的本质是始终对代码进行更新，而不仅仅是在季度末。 但是另一方面是不仅要生成代码，还要生成好的代码，基本上是没有错误的代码。 为此，您需要进行测试。

I’m not talking about testing like how the boys and me used to do it, banging through the application doing whatever we could think of and hoping it would be enough (and, of course, it never was). No, I’m talking about some real fine testing, automatic tests that put your code through its paces.

我不是在谈论像男孩和我过去那样做的测试，而是在应用程序中进行任何我们能想到的事情，并希望它足够(当然，从来没有)。 不，我说的是一些真正的精细测试，自动测试，这些测试可以使您的代码步入正轨。

PHPUnit contains a large number of standard tests (assertions) that can be performed on your code. If there are problems, an exception message is generated and you are made aware of the problem.

PHPUnit包含大量可以在您的代码上执行的标准测试(断言)。 如果存在问题，则会生成一条异常消息，并使您意识到问题所在。

Assertions are checks that you will actually build into your software. In the very excellent documentation that PHPUnit has, it talks about how you can check the validity of the code by simply printing out the values the code produces, but that is a very manual and primitive way to test the code. From there you can move to a situation where you write your code so that the code itself determines if there is a problem or not and prints out an appropriate message. This doesn’t require you to look at values and is more automated. The final step is to increase the sophistication of the test and only produce a message only if there is a problem.

断言是您将实际构建到软件中的检查。 在PHPUnit拥有的非常出色的文档中，它讨论了如何通过简单地打印出代码产生的值来检查代码的有效性，但这是一种非常手动和原始的测试代码的方法。 从那里可以转到编写代码的情况，以便代码本身确定是否存在问题并打印出适当的消息。 这不需要您查看值，而且更加自动化。 最后一步是提高测试的复杂性，并且仅在出现问题时才发出消息。

There are also a number of articles on SitePoint related to PHPUnit, starting with Michelle Sanver’s Getting Started with PHPUnit. Others include Error Condition Testing with PHPUnit by Matt Turland, and Introduction to Unit Testing in PHP with PHPUnit and Be More Assertive: Getting to Know PHPUnit Assertions by Chris Cornutt. There are also a number of articles related to how PHPUnit does or does not interface with a variety of frameworks and other software.

在SitePoint上还有许多与PHPUnit相关的文章，从Michelle Sanver的PHPUnit入门开始 。 其他内容包括Matt Turland编写的使用PHPUnit进行错误条件测试 ，以及PHP编写PHPUnit进行单元测试简介和更加自信： Chris Cornutt撰写的《 了解PHPUnit断言》 。 也有许多文章与PHPUnit如何与各种框架和其他软件进行交互有关。

编译软件 (Build Software)

And finally, you need a piece of software generally referred to as “build software” that automates the process of putting the new code in with the existing code, running through the test scripts, notifying you of any problems, and then, if all goes well, pushing the new code into your production and test environments. Examples of this include Cruise Control, Jenkins, BuildBot, Bamboo, etc.

最后，您需要一个通常被称为“构建软件”的软件，该软件可以自动执行以下步骤：将新代码与现有代码一起放入，运行测试脚本，并通知您所有问题，然后一切顺利好吧，将新代码推送到您的生产和测试环境中。 这样的示例包括Cruise Control，Jenkins，BuildBot，Bamboo等。

Jenkins is very popular with many developers and there are several articles at SitePoint related to it, starting with J. Armando Jeronymo’s two part series Continuous Integration with Jenkin. This is also a very good article on the general topic of continuous stuff.

Jenkins在许多开发人员中非常受欢迎，并且在SitePoint上有与之相关的几篇文章，从J. Armando Jeronymo的两部分系列与Jenkin连续集成开始 。 这也是关于连续性材料的一般主题的非常好的文章。

No matter what you use, the operative word here is ‘automatic’. There is no advantage to updating your site every night if it takes the efforts of five people over a two day time frame to move the new version out there. Speed is important but so is a lack of human involvement. Simple is good, automatic is better.

无论您使用什么，这里的操作词都是“自动的”。 如果在两天的时间内需要五个人的努力才能将新版本移出该站点，那么每晚更新站点都没有任何好处。 速度很重要，但缺乏人的参与也是如此。 简单是好的，自动是更好。

结论 (Conclusion)

Continuous Deployment / Delivery / Integration is not for the faint-hearted. It is demanding and has a lot of rules and requirements and they must be followed, or can you spell D-I-S-A-S-T-E-R? But for teams with a number of developers, particularly remote developers, and the business need to update the code on a very rapid and ongoing basis, it can be the only game in town.

持续部署/交付/集成不适合胆小者。 它要求很高，并且有很多规则和要求，必须遵循它们，否则您可以拼写DISASTER吗？ 但是对于拥有许多开发人员，尤其是远程开发人员的团队，以及业务需要非常快速且持续地更新代码的团队来说，它可能是唯一的游戏。

翻译自: https://www.sitepoint.com/continuous-deployment-revisited/

skysat重访周期