SAS 营销活动的 Github答案

【问题标题】：Github for SAS Marketing CampaignsSAS 营销活动的 Github
【发布时间】：2017-01-17 21:48:56
【问题描述】：

刚刚开始了一项新工作，我在其中管理 SAS 程序，这些程序收集数据、应用抑制，并最终创建一个联系信息列表，以便分发给客户的活动。

请先原谅我对我的问题的无知，但是就这样吧。

团队目前将所有代码存储在 Unix 服务器上，通过 Putty 会话执行和测试它，然后完成从创建目录、将每周代码运行文件夹（分支）中的代码合并回主代码目录等所有工作。这是非常手动的。质量检查过程也是手动的，将代码发送给另一个团队，然后他们使用 Subversion 或 Beyond Compare 来比较差异。

由于我对 GitHub 和其他存储库（SVN、BitBucket）的了解有限，似乎其中一种解决方案可以很好地简化此过程。只是好奇有人验证我的想法并确保我走在正确的轨道上，然后看看这是否可能。

实施 Github 或 Bitbucket，然后将现有的“Master Code”文件夹从服务器迁移到 repo master 分支。
当活动需要每周运行时，相应地创建一个新分支（例如 09022016、09092016 等），然后进行任何必要的更改。
1. 将更改提交到相应的每周分支，然后在诸如 Crucible 之类的地方触发代码审查。这可能吗？
2. 一旦获得批准，将更改部署到 Unix 服务器（在与 repo 中的分支同名的文件夹中），以便可以执行 .SAS 或 .ksh 文件。这是可行的吗？发生这种情况需要使用什么？
3. 如果需要将更改用于未来的活动执行，请将分支中的代码合并回主分支。
4. 重复所有未来的活动执行。

这有意义吗？我错过了什么吗？我以前是另一个组织的开发人员，但从未做过任何繁重的编码，而且所有这些流程都已经到位，所以它们就可以正常工作。

很抱歉这个冗长的问题。任何帮助将不胜感激。

编辑：更简单的问题... - 我可以使用 Github 来代替在传统文件目录中存储 SAS 程序吗？这更有意义吗？ - 我可以在签入/批准后触发从 Github 到 Unix 服务器的部署吗？ - 如果我选择，从 Github 到 Unix 的部署是否也会启动一个 SAS 程序来启动整个活动？ - 如果我没记错的话，我可以进入 Crucible，选择我想要审查的提交/代码，然后与适当的人一起启动代码审查，所以这不需要自动化。对吧？

【问题讨论】：

对于 Stack Overflow 来说太固执己见了。有很多不同的方法来解决这个问题。
感谢您的反馈，也许您可以推荐一个更好的地方来问这个问题？
@CharlieFish 我不明白为什么这一定是基于意见的，尽管它需要一些修改。
@user5568219 我会进行一些修改，以确保这是在没有意见的情况下直接提出可回答的问题，但我认为大多数情况下这是可以的。 “你能用 X 和 Y 做 Z” 可以； “这是做 XYZ 的最佳方式吗”不是（这是一种观点）。
@Joe 那么我不太明白这个问题。就个人而言，听起来OP将其发布为更多的讨论，而不是使其基于意见的实际问题。似乎没有特定的问题或问题。

标签： github sas repository bitbucket atlassian-crucible

【解决方案1】：

SAS 绝对可以用于源代码控制。如果您使用 Enterprise Guide 7.1 作为您的 IDE，那么您实际上可以在 IDE 中直接与 git 集成（并且 IDE 将项目保存为 mini-git 存储库）。

在该版本之前，或者如果您不使用 EG，您可以直接将您选择的源代码控制风格与 .sas 文件一起使用，并像任何其他编程语言一样对其进行管理。你所描述的大致是我推荐的，根据你做事的方式和服务器/等的方式进行一些微调。设置好了。

您可能会看到 SAS 与 c/java 之类的主要区别是，如果您没有在本地安装 SAS，您可能无法在本地测试您的代码。您要么需要一个 SAS 测试服务器，要么需要一个 SAS 服务器上的测试分支，与您的 prod 分支（以及 dev 分支？）分开，您保持完全独立并视为不同的服务器（即使实际上没有不同）。 SAS 成本很高，因此很难证明单独的开发/测试/生产环境服务器是合理的。

例如，我在项目中所做的事情：

/prod/PROJECT/R##/<code> - <code> is coming from SVN via pull
/test/PROJECT/R##/<code> - <code> is committed to SVN from here, and every round has a R## folder.  All of them are synced to the same trunk, separate branches.

由于我所做工作的性质，我实际上是在测试中进行开发（我需要使用 PII 进行开发，这不能在开发中使用）所以显然这在 3 层设置中会更好，但它会是那时类似。无论如何，当我以最佳方式做事时，我会在测试分支中开发、提交，然后将其拉到产品中。

我认为有趣的一件事有两个答案：您是否将回合/周放在 PROD 中。我认为你可以根据你的用例做任何一种方式。如果有必要或有用立即访问每一轮（在您的情况下为周）程序，那么您将它们分开。

如果不是这样，如果您运行该周的运行然后完成程序，最好将主运行放在一个文件夹中，该文件夹每周用最新的代码覆盖。这样你就知道你有最新的代码可用，并且知道如果你只是从 SVN 中提取，你会得到最新的代码。

最后一点。如果您每周都在运行相同的代码，除了更改一些数据驱动的细节之外，请考虑拥有一个恒定的代码库（当然除了基于非周的改进）并将这些数据驱动的细节存储在数据库中。明显的数据驱动元素：电子邮件地址、日期、电子邮件中的文本。

即使电子邮件的文本每周完全改变（例如，这是每周发送新优惠券的 Subway 电子邮件爆炸），每次提取的 SAS 代码也可能 100% 相同。您的数据库包含一些字段/表/等。存储电子邮件地址，电子邮件正文，填充，等等，并且您在 SAS 中有一些东西可以识别当前的那些（可能只是最新的，或者可能是基于您运行代码的日期的东西），拉他们出去，然后跑。

在这种情况下，没有理由每周开设分支机构或类似的事情；只有当程序发生更改时，您才会有分支，例如，如果您更改提取电子邮件地址的查询，或者添加在文本中具有链接的功能，或其他任何内容。这样一来，您就可以尽可能避免编程更改，并且大多数情况下只更改数据 - 这对 QC 来说更容易。（当然，也许数据是由某个程序生成的，它也需要QCing和分支等，但那个程序也不应该每周都更换，对吧？）

【讨论】：

关于成本 - 非 PRD 服务器的许可证有时会打折，具体取决于贵公司的安排，但我同意 SAS 仍然是一些更昂贵的软件。