刚刚开始一个新的工作，我管理SAS程序，收集数据，应用抑制，并最终创建一个联系信息列表，以便将活动分发给客户。
请事先原谅我对我的问题的无知，但现在就这样了。
团队目前将所有代码存储在Unix服务器上，通过Putty会话执行和测试，然后执行创建目录，将代码从每周代码运行文件夹（分支）合并回主代码目录等所有内容。这是非常手动的。质量检查过程也是手动的，将代码发送给另一个团队，然后他们使用Subversion或Beyond Compare来比较差异。
由于我对GitHub和其他存储库（SVN，BitBucket）知之甚少，似乎其中一个解决方案非常适合流程化这个过程。只是好奇让别人验证我的想法，并确保我走在正确的轨道上，然后看看这是否可能。
这有意义吗？我错过了什么吗？我以前是另一个组织的开发人员，但从未做过任何重编码，加上所有这些流程已经到位，所以他们只是工作。
抱歉这个冗长的问题。任何帮助将不胜感激。
编辑： 更简化的问题...... - 我可以使用Github替换传统文件目录中存储的SAS程序吗？这更有意义吗？ - 我可以在签入/批准时触发从Github到Unix服务器的部署吗？ - 如果我选择，从Github到Unix的部署是否也可以启动SAS程序来启动整个活动？ - 如果我没记错的话，我可以进入Crucible，选择我要查看的提交/代码，然后与相应的人员进行代码审查，这样就不需要自动化了。正确？
答案 0 :(得分：0)
SAS绝对可用于源代码管理。如果您使用Enterprise Guide 7.1作为IDE，那么您实际上可以直接在IDE中与git集成（并且IDE将项目保存为mini-git存储库）。
在该版本之前，或者如果您不使用EG，您可以直接使用.sas文件选择的源代码控制风格，并像其他任何编程语言一样管理它。您所描述的内容大致是我推荐的内容，并根据您的工作方式和服务器/等方式进行一些微调。已经成立。
您可能会看到SAS与c / java之类的主要区别在于，如果您没有在本地安装SAS，则可能无法在本地测试您的代码。您要么需要SAS测试服务器，要么SAS服务器上的测试分支与您的prod分支（以及开发人员？）分开，您将它们完全分开并视为不同的服务器（即使实际上并不相同）。 SAS成本很高，因此很难证明单独的dev / test / prod环境服务器的合理性。
例如，我在项目中所做的事情：
/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拉出来，你会得到最新的代码。
最后一点说明。如果您每周都运行相同的代码，除了更改一些数据驱动的细节，请考虑使用恒定的代码库（当然不是基于非周的改进）并将这些数据驱动的详细信息存储在数据库中。明显的数据驱动元素：电子邮件地址，日期，文本填写电子邮件。
即使电子邮件的文本每周都完全改变（例如，这是每周发送新优惠券的地铁电子邮件爆炸），SAS代码每次拉动都可以100％相同。您的数据库包含一些字段/表/等。存储电子邮件地址，电子邮件正文，填充，等等，你在SAS中有一些东西可以识别当前的东西（可能只是最新的，或者根据你运行代码的日期）把它们拉出来然后跑。
在这种情况下，没有理由每周分支或类似的东西;只有在程序发生变化时才会有分支，例如，如果您更改了提取电子邮件地址的查询，或者添加了在文本中包含链接的功能，或者其他任何内容。这样你就可以避免在可能的情况下进行编程更改，而且大多只是更改数据 - 这更容易进行QC。 （当然，也许数据是由程序生成的，也需要QCing和分支等，但该程序也不应该每周都要更改，对吗？）