mercurial使用

介绍 (Introduction)

As DBA’s we usually have a lot of utility scripts sitting around that we use in our daily work. Examples might include things like common administrative duties (setting up users for an application for example), installing standardized maintenance routines, or even something as complex as a home grown utility database. Often times these scripts languish on some network share or (worse) our own computers, with previous versions lost for all time when changes are made. For those of us that come from a development background, this approach makes us shiver. Keeping code that is not in some kind of version control system is inexcusable for any level of software professional, and DBA’s should be no exception. Used for quite some time by software developers, version control is a wonderful tool for administrators as well, for reasons we will discuss. But first, I want to talk a little bit about my version control system of choice, Mercurial.

作为DBA，我们通常会在日常工作中使用许多实用程序脚本。 例如，可能包括诸如常见的管理职责（例如，为应用程序设置用户），安装标准化的维护例程，甚至是与本地实用程序数据库一样复杂的事情。 通常，这些脚本在某些网络共享或（更差的）我们自己的计算机上会失效，而在进行更改时，以前的版本会一直丢失。 对于那些来自开发背景的人来说，这种方法使我们感到颤抖。 对于任何级别的软件专业人员来说，保留不在某种版本控制系统中的代码都是不可原谅的，DBA也不例外。 由于我们将讨论的原因，版本控制由软件开发人员使用了相当长的时间，对于管理员来说，版本控制也是一个很棒的工具。 但是首先，我想谈谈我选择的版本控制系统Mercurial。

水银的基础 (The Basics of Mercurial)

Why Mercurial?

为什么选择水银？

While the choice of version control system is a very subjective and personal one, there are a number of reasons why I think Mercurial is an excellent choice, especially for someone just venturing into the world of version control. Here are a number of those reasons.

虽然选择版本控制系统是一个非常主观和个人的选择，但我认为Mercurial是一个很好的选择有很多原因，特别是对于刚进入版本控制世界的人。 这些是其中一些原因。

No Server Required

无需服务器

With many version control systems a requirement is to have some kind of central server which serves as the actual repository. But with Mercurial, the repository is always local to the user’s machine. It is true that in some setups you can have a central copy of the repository, and that is certainly a useful pattern once you get into multiple user scenarios, but it is by no means a requirement. In fact, the very first tutorial given in is a very simple scenario where you simply want to track changes made to some files. Because of this, the overhead and effort required to set up your first repository is extremely small.

对于许多版本控制系统，要求具有某种充当实际存储库的中央服务器。 但是使用Mercurial，存储库始终位于用户计算机的本地。 的确，在某些设置中，您可以拥有存储库的中央副本，一旦进入多个用户场景，这肯定是有用的模式，但这绝不是必需的。 实际上， 给出的第一个教程是一个非常简单的场景，您只想跟踪对某些文件所做的更改。 因此，建立第一个存储库所需的开销和工作量非常小。

The Distributed Model

分布式模型

Mercurial is a distributed version control system, which, according to , is characterized by “[taking] a peer-to-peer approach to , as opposed to the client-server approach of centralized systems”. Since each person has a complete, independent copy of the code, it gives much more freedom to do things like more frequent commits without fear of impacting others of breaking things. I for one commit as soon as I’ve accomplished some small unit of work; this means at any given time I’m able to deliver a working version of the code with some kind of incremental improvement included, while still feeling free to experiment and continue working. It’s also very nice to not depend on having a network connection available to commit my work or compare versions (taking some time to disconnect when working is a good thing, but that’s another essay). In addition, the distributed model means that at any one time there are many copies of the code in different places, thus somewhat mitigating the risk of a single failure causing the entire repository to be lost.

Mercurial是一个分布式版本控制系统，根据 ，其特点是“ [采用]点对点方法进行 ，而不是集中式系统的客户机/服务器方法”。 由于每个人都有完整，独立的代码副本，因此它给予了更大的自由，可以执行更频繁的提交之类的事情，而不必担心会影响其他破坏事情的人。 我完成一小部分工作后就立即作出承诺； 这意味着在任何给定的时间，我都能够交付包含某些渐进式改进的工作版本的代码，同时仍然可以随意进行试验并继续工作。 不依赖于可用的网络连接来提交我的作品或比较版本也非常好（工作时花一些时间断开连接是一件好事，但这是另一篇文章）。 另外，分布式模型意味着在任何时候在不同位置都有许多代码副本，从而在某种程度上减轻了单个故障导致整个存储库丢失的风险。

It’s Free!

免费！

Mercurial is one hundred percent open source and free (as in beer) to use. There are no costs associated with licensing or infrastructure, so here again, the investment needed to try it out is extremely small.

Mercurial是100％开源的，可以免费使用（如在啤酒中）。 没有与许可或基础架构相关的成本，因此在这里再次进行尝试所需的投资非常少。

When to Use Source Control

何时使用源代码管理

Now that we’ve gone over the advantages of a tool like Mercurial, let’s talk in more general terms about specific scenarios in which version control is valuable for DBA’s. It’s true that we don’t have mountains of code to maintain like developers do, but there are still plenty of times when the tracking of changes is a useful exercise. But first, why use source control with our scripts? First, it allows us to track changes to them over time, and easily pull a previous version if something we change turns out to break things. Second, as we’ll see once we get in to some more advanced operations, we can easily create customized versions of scripts for certain scenarios while still allowing changes / enhancements to the parent script to be “pushed” down to the custom versions. This gives us the most flexibility in maintaining things. For example, perhaps we have a standard set of configurations that need to be applied to servers, but for some reason, it needs to be changed slightly for a particular server. By utilizing version control, when we make changes to the original version, we can easily apply them to the custom one.

现在，我们已经了解了Mercurial之类的工具的优势，下面让我们更笼统地讨论特定的场景，在这些场景中版本控制对于DBA来说很有价值。 的确，我们没有像开发人员那样需要维护大量的代码，但是仍然有很多次跟踪更改是有用的练习。 但是首先，为什么要在我们的脚本中使用源代码控制？ 首先，它使我们能够跟踪随着时间的变化，并且如果我们发现某些更改会破坏事物，则可以轻松获取先前的版本。 第二，正如我们将要进行的一些高级操作所看到的那样，我们可以轻松地为某些情况创建脚本的自定义版本，同时仍允许将对父脚本的更改/增强“推”到自定义版本。 这为我们提供了最灵活的维护方式。 例如，也许我们有一组标准的配置需要应用到服务器，但是由于某种原因，对于特定的服务器，它需要稍作更改。 通过使用版本控制，当我们对原始版本进行更改时，我们可以轻松地将其应用于自定义版本。

But now, let’s talk about a few specific examples of what we should be putting in source control.

但是现在，让我们谈谈应该在源代码管理中添加一些具体示例。

Server Configuration

服务器配置

When configuring the SQL Server installations we support, it’s paramount that they be kept as standardized as possible. There are two ways we can do this: 1) create a lengthy document describing how to click through the Management Studio GUI and make appropriate selections, or 2) create a script that allows us to easily and repeatedly apply standard configurations. If it’s not obvious from the description, my choice is the latter. Because really, who want to spend more time than necessary in Microsoft Word, only to subsequently spend time playing MATM (Monkey At The Monitor) clicking the mouse?

在配置我们支持SQL Server安装时，至关重要的是它们应保持尽可能的标准化。 我们可以通过两种方式执行此操作：1）创建一个冗长的文档，描述如何单击Management Studio GUI并进行适当的选择，或者2）创建一个脚本，该脚本使我们能够轻松，重复地应用标准配置。 如果从描述中不能明显看出，我选择的是后者。 因为确实是谁愿意花更多的时间在Microsoft Word中花费更多的时间，而只是随后花时间在单击鼠标上玩MATM（显示器上的猴子）？

Here are a few best practices to use when creating these configuration scripts:

以下是创建这些配置脚本时要使用的一些最佳实践：

• Give them the ability to run in a “not for real” mode, merely pointing out what they would have done rather than actually making the changes. This lets you run them once and ensure that everything will go smoothly before actually making changes to the system.
  使他们能够以“非真实”模式运行，仅指出他们会做些什么，而不是实际进行更改。 这使您可以运行它们一次，并确保在实际更改系统之前一切都能顺利进行。
• Make them output all changes that are made, including the original values and new ones if anything is changed. For example, if you are setting the “max server memory (mb)” setting (a very good thing to set indeed), output the original value as well as the one calculated and applied.
  使它们输出所有已进行的更改，包括原始值和新值（如果发生任何更改）。 例如，如果要设置“最大服务器内存（mb）”设置（确实是一项很好的设置），则输出原始值以及计算和应用的值。
• Use dynamic calculation logic whenever possible, rather than requiring human input. To expand on the previous example, let’s say that our standard for setting the maximum amount of memory we want SQL to consume is (total server memory – lesser (total server memory * 20%,2GB)). While you could let the user calculate this and input the value as a variable in the script, why not just calculate it in code?
  尽可能使用动态计算逻辑，而不需要人工输入。 为了扩展前面的示例，我们假设用于设置希望SQL使用的最大内存量的标准是（服务器总内存–更少（服务器总内存* 20％，2GB））。 尽管您可以让用户计算该值并将其值输入脚本中的变量，但为什么不仅仅在代码中计算呢？

•  SELECT @MaxServerMemory = (physical_memory_kb/1024) FROM sys.dm_os_sys_info; 	IF @MaxServerMemory * .2 > 2048	   SET @MaxServerMemory = @MaxServerMemory - 2048;	ELSE	   SET @MaxServerMemory = @MaxServerMemory - (@MaxServerMemory * .2);            	exec sp_configure 'max server memory (MB)', @MaxServerMemory; 

  This is just one example of many kinds of configurations that can and should be scripted and tracked.

  这只是可以并且应该被脚本化和跟踪的多种配置的一个示例。

  SQL Agent Jobs

  SQL代理作业

  One of a DBAs’ tasks is to create, maintain, and otherwise administrate scheduled operations on database servers via the SQL Agent system. Just like any other kind of code, SQL Agent jobs will need changes from time to time, be it in their steps, their scheduling, or various other aspects. There are also likely to be standards that need to be applied to all jobs, such as adding a notification for failures. For these reasons, scripts are again the way to go.

  DBA的任务之一是通过SQL Agent系统在数据库服务器上创建，维护和管理计划的操作。 就像任何其他类型的代码一样，SQL Agent作业将需要不时更改，无论是其步骤，进度还是其他方面。 还有可能需要将标准应用于所有作业，例如添加故障通知。 由于这些原因，脚本又是必经之路。

  Here are some things to think about when writing scripts for SQL Agent jobs:

  在为SQL Agent作业编写脚本时，需要考虑以下事项：

  • How will changes be applied? The easiest method would be to drop and recreate the job from scratch every time, however unless you do some trickery behind the scenes you’ll lose valuable history data. We may get into some ways around this in a future article, but, for now, consider creating shells of the jobs and updating them rather than blowing them away and starting from scratch each time.
    更改将如何应用？ 最简单的方法是每次都从头开始删除并重新创建作业，但是，除非您在后台进行一些欺骗，否则您将丢失宝贵的历史数据。 在以后的文章中，我们可能会对此有所了解，但是，现在，考虑创建作业的外壳并对其进行更新，而不是每次都从头开始就把它们扔掉。
  • Are there any standards that need to be applied, such as notifications on failure or capturing output in log files?
    是否需要应用任何标准，例如有关故障的通知或捕获日志文件中的输出？
  • Are there dependencies that need to be handled either as part of the script or as a separate one, such as operators, proxies, etc?
    是否存在需要作为脚本的一部分或作为单独的脚本（例如运算符，代理等）处理的依赖关系？

  Utility Scripts

  实用脚本

  Every DBA needs to have a set of utility scripts and code to help them in their daily work. This has numerous advantages over going the route of treating everything as one-offs, such as:

  每个DBA都需要一套实用程序脚本和代码来帮助他们进行日常工作。 与将所有事物视为一次性的路线相比，它具有许多优势，例如：

  • It will be easy to find scripts for various common situations, thereby letting you get your work done faster and easing troubleshooting.
    可以轻松找到各种常见情况的脚本，从而使您更快地完成工作并简化故障排除。
  • By using scripts to complete your work you can ensure it is done in a repeatable and consistent way.
    通过使用脚本来完成您的工作，您可以确保以可重复且一致的方式完成该工作。

  Just as developers need to use version control to track changes to their work, so should we.

  正如开发人员需要使用版本控制来跟踪对其工作所做的更改一样，我们也应该这样做。

  Here are a couple ways to find things that you should be using scripts for:

  这里有几种查找脚本的方法：

  • Do you have checklists? If so, these are a great candidate for scripting, since you already have done the hard work of defining what needs to be done.
    你有清单吗？ 如果是这样，那么这些都是编写脚本的理想选择，因为您已经完成了定义需要完成的工作。
  • What do you spend most of your time doing throughout the day? Where there’s work, there’s an opportunity for scripting and automation.
    您一整天大部分时间都在做什么？ 哪里有工作，哪里就有脚本和自动化的机会。
  • What do people constantly ask you about? If you’re constantly getting questions about how to set up Service Broker, maybe it’s time to create a script that does it all and simply hand that off to interested parties.
    人们经常问你什么？ 如果您经常遇到有关如何设置Service Broker的问题，也许是时候创建一个能够完成所有任务并将其交给相关方的脚本了。

  结论 (Conclusion)

  In this first installment of the series, we’ve laid out a case for why DBA’s should use version control software, with some specific advantages of the Mercurial product. In the coming installment, we’ll get a repository created (which as you’ll see is far easier than it sounds), commit our first file, and show how you can view changes made to a file and commit them safely. Finally, we’ll see how we can easily remove a change we accidentally made. Stay tuned!

  在该系列的第一部分中，我们提出了一个案例，说明了为什么DBA应该使用版本控制软件，以及Mercurial产品的某些特定优点。 在下一部分中，我们将创建一个存储库（您将看到它比听起来容易得多），提交我们的第一个文件，并展示如何查看对文件所做的更改并安全地提交它们。 最后，我们将看到如何轻松删除意外进行的更改。 敬请关注！

  翻译自:

  mercurial使用