http://www.molss.gov.cn/gb/news/2007-06/30/content_184630.htm

B)中华人民共和国劳动合同法实施条例(解释劳动法实施)

http://www.gov.cn/flfg/2008-09/19/content_1099500.htm

C)关于确立劳动关系有关事项的通知

http://www.law-lib.com/law/law_view.asp?id=92395

D)上海市女职工劳动保护办法

http://www.shanghai.gov.cn/shanghai/node2314/node3124/node3125/node3133/userobject6ai655.html

·                     C)的相关内容：

     用人单位未与劳动者签订劳动合同，认定双方存在劳动关系时可参照下列凭证：

(一)工资支付凭证或记录(职工工资发放花名册)、缴纳各项社会保险费的记录；

(二)用人单位向劳动者发放的“工作证”、“服务证”等能够证明身份的证件；

·                     B) 的相关内容：

第六条        用人单位自用工之日起超过一个月不满一年未与劳动者订立书面劳动合同的，应当依照劳动合同法第八十二条的规定向劳动者每月支付两倍的工资，并与劳动者补订书面劳动合同；劳动者不与用人单位订立书面劳动合同的，用人单位应当书面通知劳动者终止劳动关系，并依照劳动合同法第四十七条的规定支付经济补偿。(1，相当于给2倍工资，2，补合同，3，如果辞退，再按照有合同补偿）

第二十七条　劳动合同法第四十七条规定的经济补偿的月工资按照劳动者应得工资计算，包括计时工资或者计件工资以及奖金。

·                     A)的相关内容：

     第四十二条　劳动者有下列情形之一的，用人单位不得依照本法第四十条、第四十一条的规定解除劳动合同：

        （四）女职工在孕期、产期、哺乳期的

 　第四十七条　经济补偿按劳动者在本单位工作的年限，每满一年支付一个月工资的标准向劳动者支付。六个月以上不满一年的，按一年计算；不满六个月的，向劳动者支付半个月工资的经济补偿。

     第八十二条　用人单位自用工之日起超过一个月不满一年未与劳动者订立书面劳动合同的，应当向劳动者每月支付二倍的工资。

    用人单位违反本法规定不与劳动者订立无固定期限劳动合同的，自应当订立无固定期限劳动合同之日起向劳动者每月支付二倍的工资。

     第八十七条　用人单位违反本法规定解除或者终止劳动合同的，应当依照本法第四十七条规定的经济补偿标准的二倍向劳动者支付赔偿金。

 第十四条　无固定期限劳动合同，是指用人单位与劳动者约定无确定终止时间的劳动合同。

    用人单位与劳动者协商一致，可以订立无固定期限劳动合同。有下列情形之一，劳动者提出或者同意续订、订立劳动合同的，除劳动者提出订立固定期限劳动合同外，应当订立无固定期限劳动合同：

    （一）劳动者在该用人单位连续工作满十年的；

    （二）用人单位初次实行劳动合同制度或者国有企业改制重新订立劳动合同时，劳动者在该用人单位连续工作满十年且距法定退休年龄不足十年的；

    （三）连续订立二次固定期限劳动合同，且劳动者没有本法第三十九条和第四十条第一项、第二项规定的情形，续订劳动合同的。

    用人单位自用工之日起满一年不与劳动者订立书面劳动合同的，视为用人单位与劳动者已订立无固定期限劳动合同。

·                     D) 的相关内容：

第十一条对妊娠期的女职工，不应延长其劳动时间；

第十四条女职工产假分别按下列情况执行：

     （一）单胎顺产者，给予产假九十天，其中产前休息十五天，产后休息七十五天。

第十五条女职工生育后，在其婴儿一周岁内应照顾其在每班劳动时间内授乳两次（包括人工喂养）。每次单胎纯授乳时间为三十分钟，亦可将两次授乳时间合并使用。多胞胎生育者，每多生一胎，每次哺乳时间增加三十分钟。

 第十八条女职工在产假期间的工资照发。按本规定享受的产前假和哺乳假的工资按本人原工资的百分之八十发给。单位增加工资时，女职工按规定享受的产前假、产假、哺乳假，应作出勤对待。

·                     结论：

1）      认定劳动关系：工作证

2）      是否签合同

3）      如果没签合同，怎么补偿（1，相当于给2倍工资，2，补合同，3，如果辞退，再按照有合同补偿）

4）      如果是固定合同，怎么补偿（N+1）

5）      如果是无期合同，2倍

6）      孕妇怎么处理？

1、公司辞退孕妇的补偿情况标准是怎样？

答：发放工资到哺乳期满；按工作年限计算经济补偿金。

2、公司是否可以以我的考核和我是孕产妇不能胜任工作为由对我进行降职降级降薪处理？

答：不可以。

我们的工资分为基本工资（约占1/4)+岗位工资+绩效工资等。是否可能出现只要不降低我的基本工资就是合法的行为？

答：不合理。工资是包括了岗位工资和绩效工资。

3、如果公司依法破产，我是否有向集团主张赔偿的权利？

答：破产也可以主张权利，在破产财产中优先演戏偿。

4、如果可能需要诉诸法律，我应该准备哪些方面的举证？

答：存在劳动关系的证据最重要，此外，工资条、怀孕的证据、结婚证、准生证

也比较重要。（按照劳动法42条，不得解除三期【孕期、产期、哺乳期】妇女。那么如果一定要违反劳动法解除劳动关系，只能按照违反劳动法，按照第八十七条进行二倍赔偿，也就是3倍）

案例:

http://www.tianya.cn/publicforum/content/law/1/119373.shtml

案情：A公司辞退B孕妇（不考虑B可能存在的过错，假设A毫无道理毫无依据的辞退B孕妇）。

　　一审结果：判赔全额孕期工资、全额产期（晚育还加了15天）工资、75%的哺乳期工资，并以入职时间至三期届满为劳动合同关系存续期间计算在职时间，然后以该在职时间按照《劳动合同法》第八十七条判赔了赔偿金（即合法解除的补偿金的双倍）。一审不是我代理的。

　　二审A公司找到我，我想当然的以为，按照《劳动合同法》第八十七条的规定，劳动者可以选择要求继续履行，不要求继续履行的，应当仅支付双倍补偿即可，一审判决属适用法律错误。

前几天在给人解释Windows是如何通过Kerberos进行Authentication的时候，讲了半天也别把那位老兄讲明白，还差点把自己给绕进去。后来想想原因有以下两点：对于一个没有完全不了解Kerberos的人来说，Kerberos的整个Authentication过程确实不好理解——一会儿以这个Key进行加密、一会儿又要以另一个Key进行加密，确实很容易把人给弄晕；另一方面是我讲解方式有问题，一开始就从Kerberos的3个Sub-protocol全面讲述整个Authentication 过程，对于一个完全不了解Kerberos的人来说要求也忒高了点。为此，我花了一些时间写了这篇文章，尽量以由浅入深、层层深入的方式讲述我所理解的基于Kerberos的Windows Network Authentication，希望这篇文章能帮助那些对Kerberos不明就里的人带来一丝帮助。对于一些不对的地方，欢迎大家批评指正。

一、 基本原理

Authentication解决的是“如何证明某个人确确实实就是他或她所声称的那个人”的问题。对于如何进行Authentication，我们采用这样的方法：如果一个秘密（secret）仅仅存在于A和B，那么有个人对B声称自己就是A，B通过让A提供这个秘密来证明这个人就是他或她所声称的A。这个过程实际上涉及到3个重要的关于Authentication的方面：

• Secret如何表示。
• A如何向B提供Secret。
• B如何识别Secret。

基于这3个方面，我们把Kerberos Authentication进行最大限度的简化：整个过程涉及到Client和Server，他们之间的这个Secret我们用一个Key（KServer-Client）来表示。Client为了让Server对自己进行有效的认证，向对方提供如下两组信息：

• 代表Client自身Identity的信息，为了简便，它以明文的形式传递。
• 将Client的Identity使用KServer-Client作为Public Key、并采用对称加密算法进行加密。

由于KServer-Client仅仅被Client和Server知晓，所以被Client使用KServer-Client加密过的Client Identity只能被Client和Server解密。同理，Server接收到Client传送的这两组信息，先通过KServer-Client对后者进行解密，随后将机密的数据同前者进行比较，如果完全一样，则可以证明Client能过提供正确的KServer-Client，而这个世界上，仅仅只有真正的Client和自己知道KServer-Client，所以可以对方就是他所声称的那个人。

Keberos大体上就是按照这样的一个原理来进行Authentication的。但是Kerberos远比这个复杂，我将在后续的章节中不断地扩充这个过程，知道Kerberos真实的认证过程。为了使读者更加容易理解后续的部分，在这里我们先给出两个重要的概念：

• Long-term Key/Master Key：在Security的领域中，有的Key可能长期内保持不变，比如你在密码，可能几年都不曾改变，这样的Key、以及由此派生的Key被称为Long-term Key。对于Long-term Key的使用有这样的原则：被Long-term Key加密的数据不应该在网络上传输。原因很简单，一旦这些被Long-term Key加密的数据包被恶意的网络监听者截获，在原则上，只要有充足的时间，他是可以通过计算获得你用于加密的Long-term Key的——任何加密算法都不可能做到绝对保密。

在一般情况下，对于一个Account来说，密码往往仅仅限于该Account的所有者知晓，甚至对于任何Domain的Administrator，密码仍然应该是保密的。但是密码却又是证明身份的凭据，所以必须通过基于你密码的派生的信息来证明用户的真实身份，在这种情况下，一般将你的密码进行Hash运算得到一个Hash code, 我们一般管这样的Hash Code叫做Master Key。由于Hash Algorithm是不可逆的，同时保证密码和Master Key是一一对应的，这样既保证了你密码的保密性，有同时保证你的Master Key和密码本身在证明你身份的时候具有相同的效力。

• Short-term Key/Session Key：由于被Long-term Key加密的数据包不能用于网络传送，所以我们使用另一种Short-term Key来加密需要进行网络传输的数据。由于这种Key只在一段时间内有效，即使被加密的数据包被黑客截获，等他把Key计算出来的时候，这个Key早就已经过期了。

二、引入Key Distribution: KServer-Client从何而来

上面我们讨论了Kerberos Authentication的基本原理：通过让被认证的一方提供一个仅限于他和认证方知晓的Key来鉴定对方的真实身份。而被这个Key加密的数据包需要在Client和Server之间传送，所以这个Key不能是一个Long-term Key，而只可能是Short-term Key，这个可以仅仅在Client和Server的一个Session中有效，所以我们称这个Key为Client和Server之间的Session Key（SServer-Client）。

现在我们来讨论Client和Server如何得到这个SServer-Client。在这里我们要引入一个重要的角色：Kerberos Distribution Center-KDC。KDC在整个Kerberos Authentication中作为Client和Server共同信任的第三方起着重要的作用，而Kerberos的认证过程就是通过这3方协作完成。顺便说一下，Kerberos起源于希腊神话，是一支守护着冥界长着3个头颅的神犬，在keberos Authentication中，Kerberos的3个头颅代表中认证过程中涉及的3方：Client、Server和KDC。

对于一个Windows Domain来说，Domain Controller扮演着KDC的角色。KDC维护着一个存储着该Domain中所有帐户的Account Database（一般地，这个Account Database由AD来维护），也就是说，他知道属于每个Account的名称和派生于该Account Password的Master Key。而用于Client和Server相互认证的SServer-Client就是有KDC分发。下面我们来看看KDC分发SServer-Client的过程。

通过下图我们可以看到KDC分发SServer-Client的简单的过程：首先Client向KDC发送一个对SServer-Client的申请。这个申请的内容可以简单概括为“我是某个Client，我需要一个Session Key用于访问某个Server ”。KDC在接收到这个请求的时候，生成一个Session Key，为了保证这个Session Key仅仅限于发送请求的Client和他希望访问的Server知晓，KDC会为这个Session Key生成两个Copy，分别被Client和Server使用。然后从Account database中提取Client和Server的Master Key分别对这两个Copy进行对称加密。对于后者，和Session Key一起被加密的还包含关于Client的一些信息。

KDC现在有了两个分别被Client和Server 的Master Key加密过的Session Key，这两个Session Key如何分别被Client和Server获得呢？也许你 马上会说，KDC直接将这两个加密过的包发送给Client和Server不就可以了吗，但是如果这样做，对于Server来说会出现下面 两个问题：

• 由于一个Server会面对若干不同的Client, 而每个Client都具有一个不同的Session Key。那么Server就会为所有的Client维护这样一个Session Key的列表，这样做对于Server来说是比较麻烦而低效的。
• 由于网络传输的不确定性，可能出现这样一种情况：Client很快获得Session Key，并将这个Session Key作为Credential随同访问请求发送到Server，但是用于Server的Session Key确还没有收到，并且很有可能承载这个Session Key的永远也到不了Server端，Client将永远得不到认证。

为了解决这个问题，Kerberos的做法很简单，将这两个被加密的Copy一并发送给Client，属于Server的那份由Client发送给Server。

可能有人会问，KDC并没有真正去认证这个发送请求的Client是否真的就是那个他所声称的那个人，就把Session Key发送给他，会不会有什么问题？如果另一个人（比如Client B）声称自己是Client A，他同样会得到Client A和Server的Session Key，这会不会有什么问题？实际上不存在问题，因为Client B声称自己是Client A，KDC就会使用Client A的Password派生的Master Key对Session Key进行加密，所以真正知道Client A 的Password的一方才会通过解密获得Session Key。 

三、引入Authenticator - 为有效的证明自己提供证据

通过上面的过程，Client实际上获得了两组信息：一个通过自己Master Key加密的Session Key，另一个被Sever的Master Key加密的数据包，包含Session Key和关于自己的一些确认信息。通过第一节，我们说只要通过一个双方知晓的Key就可以对对方进行有效的认证，但是在一个网络的环境中，这种简单的做法是具有安全漏洞，为此,Client需要提供更多的证明信息，我们把这种证明信息称为Authenticator，在Kerberos的Authenticator实际上就是关于Client的一些信息和当前时间的一个Timestamp（关于这个安全漏洞和Timestamp的作用，我将在后面解释）。

在这个基础上，我们再来看看Server如何对Client进行认证：Client通过自己的Master Key对KDC加密的Session Key进行解密从而获得Session Key，随后创建Authenticator（Client Info + Timestamp）并用Session Key对其加密。最后连同从KDC获得的、被Server的Master Key加密过的数据包（Client Info + Session Key）一并发送到Server端。我们把通过Server的Master Key加密过的数据包称为Session Ticket。

当Server接收到这两组数据后，先使用他自己的Master Key对Session Ticket进行解密，从而获得Session Key。随后使用该Session Key解密Authenticator，通过比较Authenticator中的Client Info和Session Ticket中的Client Info从而实现对Client的认证。

为什么要使用Timestamp？

到这里，很多人可能认为这样的认证过程天衣无缝：只有当Client提供正确的Session Key方能得到Server的认证。但是在现实环境中，这存在很大的安全漏洞。

我们试想这样的现象：Client向Server发送的数据包被某个恶意网络监听者截获，该监听者随后将数据包座位自己的Credential冒充该Client对Server进行访问，在这种情况下，依然可以很顺利地获得Server的成功认证。为了解决这个问题，Client在Authenticator中会加入一个当前时间的Timestamp。

在Server对Authenticator中的Client Info和Session Ticket中的Client Info进行比较之前，会先提取Authenticator中的Timestamp，并同当前的时间进行比较，如果他们之间的偏差超出一个可以接受的时间范围（一般是5mins），Server会直接拒绝该Client的请求。在这里需要知道的是，Server维护着一个列表，这个列表记录着在这个可接受的时间范围内所有进行认证的Client和认证的时间。对于时间偏差在这个可接受的范围中的Client，Server会从这个这个列表中获得最近一个该Client的认证时间，只有当Authenticator中的Timestamp晚于通过一个Client的最近的认证时间的情况下，Server采用进行后续的认证流程。

Time Synchronization的重要性

上述 基于Timestamp的认证机制只有在Client和Server端的时间保持同步的情况才有意义。所以保持Time Synchronization在整个认证过程中显得尤为重要。在一个Domain中，一般通过访问同一个Time Service获得当前时间的方式来实现时间的同步。

双向认证（Mutual Authentication）

Kerberos一个重要的优势在于它能够提供双向认证：不但Server可以对Client 进行认证，Client也能对Server进行认证。

具体过程是这样的，如果Client需要对他访问的Server进行认证，会在它向Server发送的Credential中设置一个是否需要认证的Flag。Server在对Client认证成功之后，会把Authenticator中的Timestamp提出出来，通过Session Key进行加密，当Client接收到并使用Session Key进行解密之后，如果确认Timestamp和原来的完全一致，那么他可以认定Server正式他试图访问的Server。

那么为什么Server不直接把通过Session Key进行加密的Authenticator原样发送给Client，而要把Timestamp提取出来加密发送给Client呢？原因在于防止恶意的监听者通过获取的Client发送的Authenticator冒充Server获得Client的认证。


四、引入Ticket Granting  Service

通过上面的介绍，我们发现Kerberos实际上一个基于Ticket的认证方式。Client想要获取Server端的资源，先得通过Server的认证；而认证的先决条件是Client向Server提供从KDC获得的一个有Server的Master Key进行加密的Session Ticket（Session Key + Client Info）。可以这么说，Session Ticket是Client进入Server领域的一张门票。而这张门票必须从一个合法的Ticket颁发机构获得，这个颁发机构就是Client和Server双方信任的KDC， 同时这张Ticket具有超强的防伪标识：它是被Server的Master Key加密的。对Client来说， 获得Session Ticket是整个认证过程中最为关键的部分。

上面我们只是简单地从大体上说明了KDC向Client分发Ticket的过程，而真正在Kerberos中的Ticket Distribution要复杂一些。为了更好的说明整个Ticket Distribution的过程，我在这里做一个类比。现在的股事很火爆，上海基本上是全民炒股，我就举一个认股权证的例子。有的上市公司在股票配股、增发、基金扩募、股份减持等情况会向公众发行认股权证，认股权证的持有人可以凭借这个权证认购一定数量的该公司股票，认股权证是一种具有看涨期权的金融衍生产品。

而我们今天所讲的Client获得Ticket的过程也和通过认股权证购买股票的过程类似。如果我们把Client提供给Server进行认证的Ticket比作股票的话，那么Client在从KDC那边获得Ticket之前，需要先获得这个Ticket的认购权证，这个认购权证在Kerberos中被称为TGT：Ticket Granting Ticket，TGT的分发方仍然是KDC。

我们现在来看看Client是如何从KDC处获得TGT的：首先Client向KDC发起对TGT的申请，申请的内容大致可以这样表示：“我需要一张TGT用以申请获取用以访问所有Server的Ticket”。KDC在收到该申请请求后，生成一个用于该Client和KDC进行安全通信的Session Key（SKDC-Client）。为了保证该Session Key仅供该Client和自己使用，KDC使用Client的Master Key和自己的Master Key对生成的Session Key进行加密，从而获得两个加密的SKDC-Client的Copy。对于后者，随SKDC-Client一起被加密的还包含以后用于鉴定Client身份的关于Client的一些信息。最后KDC将这两份Copy一并发送给Client。这里有一点需要注意的是：为了免去KDC对于基于不同Client的Session Key进行维护的麻烦，就像Server不会保存Session Key（SServer-Client）一样，KDC也不会去保存这个Session Key（SKDC-Client），而选择完全靠Client自己提供的方式。

当Client收到KDC的两个加密数据包之后，先使用自己的Master Key对第一个Copy进行解密，从而获得KDC和Client的Session Key（SKDC-Client），并把该Session 和TGT进行缓存。有了Session Key和TGT，Client自己的Master Key将不再需要，因为此后Client可以使用SKDC-Client向KDC申请用以访问每个Server的Ticket，相对于Client的Master Key这个Long-term Key，SKDC-Client是一个Short-term Key，安全保证得到更好的保障，这也是Kerberos多了这一步的关键所在。同时需要注意的是SKDC-Client是一个Session Key，他具有自己的生命周期，同时TGT和Session相互关联，当Session Key过期，TGT也就宣告失效，此后Client不得不重新向KDC申请新的TGT，KDC将会生成一个不同Session Key和与之关联的TGT。同时，由于Client Log off也导致SKDC-Client的失效，所以SKDC-Client又被称为Logon Session Key。

接下来，我们看看Client如何使用TGT来从KDC获得基于某个Server的Ticket。在这里我要强调一下，Ticket是基于某个具体的Server的，而TGT则是和具体的Server无关的，Client可以使用一个TGT从KDC获得基于不同Server的Ticket。我们言归正传，Client在获得自己和KDC的Session Key（SKDC-Client）之后，生成自己的Authenticator以及所要访问的Server名称的并使用SKDC-Client进行加密。随后连同TGT一并发送给KDC。KDC使用自己的Master Key对TGT进行解密，提取Client Info和Session Key（SKDC-Client），然后使用这个SKDC-Client解密Authenticator获得Client Info，对两个Client Info进行比较进而验证对方的真实身份。验证成功，生成一份基于Client所要访问的Server的Ticket给Client，这个过程就是我们第二节中介绍的一样了。 

五、Kerberos的3个Sub-protocol：整个Authentication

通过以上的介绍，我们基本上了解了整个Kerberos authentication的整个流程：整个流程大体上包含以下3个子过程：

1. Client向KDC申请TGT（Ticket Granting Ticket）。
2. Client通过获得TGT向DKC申请用于访问Server的Ticket。
3. Client最终向为了Server对自己的认证向其提交Ticket。

不过上面的介绍离真正的Kerberos Authentication还是有一点出入。Kerberos整个认证过程通过3个sub-protocol来完成。这个3个Sub-Protocol分别完成上面列出的3个子过程。这3个sub-protocol分别为：

1. Authentication Service Exchange
2. Ticket Granting Service Exchange
3. Client/Server Exchange

下图简单展示了完成这个3个Sub-protocol所进行Message Exchange。

1． Authentication Service Exchange

通过这个Sub-protocol，KDC（确切地说是KDC中的Authentication Service）实现对Client身份的确认，并颁发给该Client一个TGT。具体过程如下：

Client向KDC的Authentication Service发送Authentication Service Request（KRB_AS_REQ）, 为了确保KRB_AS_REQ仅限于自己和KDC知道，Client使用自己的Master Key对KRB_AS_REQ的主体部分进行加密（KDC可以通过Domain 的Account Database获得该Client的Master Key）。KRB_AS_REQ的大体包含以下的内容：

• Pre-authentication data：包含用以证明自己身份的信息。说白了，就是证明自己知道自己声称的那个account的Password。一般地，它的内容是一个被Client的Master key加密过的Timestamp。
• Client name & realm: 简单地说就是Domain name\Client
• Server Name：注意这里的Server Name并不是Client真正要访问的Server的名称，而我们也说了TGT是和Server无关的（Client只能使用Ticket，而不是TGT去访问Server）。这里的Server Name实际上是KDC的Ticket Granting Service的Server Name。

AS（Authentication Service）通过它接收到的KRB_AS_REQ验证发送方的是否是在Client name & realm中声称的那个人，也就是说要验证发送放是否知道Client的Password。所以AS只需从Account Database中提取Client对应的Master Key对Pre-authentication data进行解密，如果是一个合法的Timestamp，则可以证明发送放提供的是正确无误的密码。验证通过之后，AS将一份Authentication Service Response（KRB_AS_REP）发送给Client。KRB_AS_REQ主要包含两个部分：本Client的Master Key加密过的Session Key（SKDC-Client：Logon Session Key）和被自己（KDC）加密的TGT。而TGT大体又包含以下的内容：

• Session Key: SKDC-Client：Logon Session Key
• Client name & realm: 简单地说就是Domain name\Client
• End time: TGT到期的时间。

Client通过自己的Master Key对第一部分解密获得Session Key（SKDC-Client：Logon Session Key）之后，携带着TGT便可以进入下一步：TGS（Ticket Granting Service）Exchange。

2． TGS（Ticket Granting Service）Exchange

TGS（Ticket Granting Service）Exchange通过Client向KDC中的TGS（Ticket Granting Service）发送Ticket Granting Service Request（KRB_TGS_REQ）开始。KRB_TGS_REQ大体包含以下的内容：

• TGT：Client通过AS Exchange获得的Ticket Granting Ticket，TGT被KDC的Master Key进行加密。
• Authenticator：用以证明当初TGT的拥有者是否就是自己，所以它必须以TGT的办法方和自己的Session Key（SKDC-Client：Logon Session Key）来进行加密。
• Client name & realm: 简单地说就是Domain name\Client。
• Server name & realm: 简单地说就是Domain name\Server，这回是Client试图访问的那个Server。

TGS收到KRB_TGS_REQ在发给Client真正的Ticket之前，先得整个Client提供的那个TGT是否是AS颁发给它的。于是它不得不通过Client提供的Authenticator来证明。但是Authentication是通过Logon Session Key（SKDC-Client）进行加密的，而自己并没有保存这个Session Key。所以TGS先得通过自己的Master Key对Client提供的TGT进行解密，从而获得这个Logon Session Key（SKDC-Client），再通过这个Logon Session Key（SKDC-Client）解密Authenticator进行验证。验证通过向对方发送Ticket Granting Service Response（KRB_TGS_REP）。这个KRB_TGS_REP有两部分组成：使用Logon Session Key（SKDC-Client）加密过用于Client和Server的Session Key（SServer-Client）和使用Server的Master Key进行加密的Ticket。该Ticket大体包含以下一些内容：

• Session Key：SServer-Client。
• Client name & realm: 简单地说就是Domain name\Client。
• End time: Ticket的到期时间。

Client收到KRB_TGS_REP，使用Logon Session Key（SKDC-Client）解密第一部分后获得Session Key（SServer-Client）。有了Session Key和Ticket，Client就可以之间和Server进行交互，而无须在通过KDC作中间人了。所以我们说Kerberos是一种高效的认证方式，它可以直接通过Client和Server双方来完成，不像Windows NT 4下的NTLM认证方式，每次认证都要通过一个双方信任的第3方来完成。

我们现在来看看 Client如果使用Ticket和Server怎样进行交互的，这个阶段通过我们的第3个Sub-protocol来完成：CS（Client/Server ）Exchange。

3． CS（Client/Server ）Exchange

这个已经在本文的第二节中已经介绍过，对于重复发内容就不再累赘了。Client通过TGS Exchange获得Client和Server的Session Key（SServer-Client），随后创建用于证明自己就是Ticket的真正所有者的Authenticator，并使用Session Key（SServer-Client）进行加密。最后将这个被加密过的Authenticator和Ticket作为Application Service Request（KRB_AP_REQ）发送给Server。除了上述两项内容之外，KRB_AP_REQ还包含一个Flag用于表示Client是否需要进行双向验证（Mutual Authentication）。

Server接收到KRB_AP_REQ之后，通过自己的Master Key解密Ticket，从而获得Session Key（SServer-Client）。通过Session Key（SServer-Client）解密Authenticator，进而验证对方的身份。验证成功，让Client访问需要访问的资源，否则直接拒绝对方的请求。

对于需要进行双向验证，Server从Authenticator提取Timestamp，使用Session Key（SServer-Client）进行加密，并将其发送给Client用于Client验证Server的身份。


六、User2User Sub-Protocol：有效地保障Server的安全

通过3个Sub-protocol的介绍，我们可以全面地掌握整个Kerberos的认证过程。实际上，在Windows 2000时代，基于Kerberos的Windows Authentication就是按照这样的工作流程来进行的。但是我在上面一节结束的时候也说了，基于3个Sub-protocol的Kerberos作为一种Network Authentication是具有它自己的局限和安全隐患的。我在整篇文章一直在强调这样的一个原则：以某个Entity的Long-term Key加密的数据不应该在网络中传递。原因很简单，所有的加密算法都不能保证100%的安全，对加密的数据进行解密只是一个时间的过程，最大限度地提供安全保障的做法就是：使用一个Short-term key（Session Key）代替Long-term Key对数据进行加密，使得恶意用户对其解密获得加密的Key时，该Key早已失效。但是对于3个Sub-Protocol的C/S Exchange，Client携带的Ticket却是被Server Master Key进行加密的，这显现不符合我们提出的原则，降低Server的安全系数。

所以我们必须寻求一种解决方案来解决上面的问题。这个解决方案很明显：就是采用一个Short-term的Session Key，而不是Server Master Key对Ticket进行加密。这就是我们今天要介绍的Kerberos的第4个Sub-protocol：User2User Protocol。我们知道，既然是Session Key，仅必然涉及到两方，而在Kerberos整个认证过程涉及到3方：Client、Server和KDC，所以用于加密Ticket的只可能是Server和KDC之间的Session Key（SKDC-Server）。

我们知道Client通过在AS Exchange阶段获得的TGT从KDC那么获得访问Server的Ticket。原来的Ticket是通过Server的Master Key进行加密的，而这个Master Key可以通过Account Database获得。但是现在KDC需要使用Server和KDC之间的SKDC-Server进行加密，而KDC是不会维护这个Session Key，所以这个Session Key只能靠申请Ticket的Client提供。所以在AS Exchange和TGS Exchange之间，Client还得对Server进行请求已获得Server和KDC之间的Session Key（SKDC-Server）。而对于Server来说，它可以像Client一样通过AS Exchange获得他和KDC之间的Session Key（SKDC-Server）和一个封装了这个Session Key并被KDC的Master Key进行加密的TGT，一旦获得这个TGT，Server会缓存它，以待Client对它的请求。我们现在来详细地讨论这一过程。

上图基本上翻译了基于User2User的认证过程，这个过程由4个步骤组成。我们发现较之我在上面一节介绍的基于传统3个Sub-protocol的认证过程，这次对了第2部。我们从头到尾简单地过一遍：

1. AS Exchange：Client通过此过程获得了属于自己的TGT，有了此TGT，Client可凭此向KDC申请用于访问某个Server的Ticket。
2. 这一步的主要任务是获得封装了Server和KDC的Session Key（SKDC-Server）的属于Server的TGT。如果该TGT存在于Server的缓存中，则Server会直接将其返回给Client。否则通过AS Exchange从KDC获取。
3. TGS Exchange：Client通过向KDC提供自己的TGT，Server的TGT以及Authenticator向KDC申请用于访问Server的Ticket。KDC使用先用自己的Master Key解密Client的TGT获得SKDC-Client，通过SKDC-Client解密Authenticator验证发送者是否是TGT的真正拥有者，验证通过再用自己的Master Key解密Server的TGT获得KDC和Server 的Session Key（SKDC-Server），并用该Session Key加密Ticket返回给Client。
4. C/S Exchange：Client携带者通过KDC和Server 的Session Key（SKDC-Server）进行加密的Ticket和通过Client和Server的Session Key（SServer-Client）的Authenticator访问Server，Server通过SKDC-Server解密Ticket获得SServer-Client，通过SServer-Client解密Authenticator实现对Client的验证。

这就是整个过程。

七、Kerberos的优点

分析整个Kerberos的认证过程之后，我们来总结一下Kerberos都有哪些优点：

1．较高的Performance

虽然我们一再地说Kerberos是一个涉及到3方的认证过程：Client、Server、KDC。但是一旦Client获得用过访问某个Server的Ticket，该Server就能根据这个Ticket实现对Client的验证，而无须KDC的再次参与。和传统的基于Windows NT 4.0的每个完全依赖Trusted Third Party的NTLM比较，具有较大的性能提升。

2．实现了双向验证（Mutual Authentication）

传统的NTLM认证基于这样一个前提：Client访问的远程的Service是可信的、无需对于进行验证，所以NTLM不曾提供双向验证的功能。这显然有点理想主义，为此Kerberos弥补了这个不足：Client在访问Server的资源之前，可以要求对Server的身份执行认证。

3．对Delegation的支持

Impersonation和Delegation是一个分布式环境中两个重要的功能。Impersonation允许Server在本地使用Logon 的Account执行某些操作，Delegation需用Server将logon的Account带入到另过一个Context执行相应的操作。NTLM仅对Impersonation提供支持，而Kerberos通过一种双向的、可传递的（Mutual 、Transitive）信任模式实现了对Delegation的支持。

4．互操作性（Interoperability）

Kerberos最初由MIT首创，现在已经成为一行被广泛接受的标准。所以对于不同的平台可以进行广泛的互操作。

摘要：本文ASP.NET应用程序身份验证的概念，介绍了各种身份验证模式并进行了比较，阐述了选择身份验证模式的机制，并给出了一种基于窗体身份验证模式的实现方法。

关键字：身份验证 authentication ASP.NET WEB应用

1.身份验证概念 任何成功的应用程序安全策略的基础都是稳固的身份验证和授权手段，以及提供机密数据的保密性和完整性的安全通讯。
身份验证（authentication）是一个标识应用程序客户端的过程，这里的客户端可能包括终端用户、服务、进程或计算机，通过了身份验证的客户端被称为主体（principal）。身份验证可以跨越应用程序的多个层发生。终端用户起初由Web应用程序进行身份验证，通常根据用户名和密码进行；随后终端用户的请求由中间层应用程序服务器和数据库服务器进行处理，这过程中也将进行身份验证以便验证并处理这些请求。
图1列出了各种安全技术以及每种技术所提供的主要验证方式。
2. 身份验证模式 如图1所示，Windows 2000上的.NET框架上提供了以下几种身份验证：
ASP.NET身份验证模式 Enterprise Services身份验证 SQL Server身份验证 2.1 ASP.NET身份验证模式 ASP.NET身份验证模式包括Windows、Forms（窗体）、Passport（护照）和None（无）。
2.1.1 Windows身份验证 使用这种身份验证模式时，ASP.NET依赖于IIS对用户进行验证，并创建一个Windows访问令牌来表示已通过验证的标识。IIS提供以下几种身份验证机制：
基本身份验证简要身份验证集成Windows身份验证证书身份验证匿名身份验证 2.1.2 护照身份验证 使用这种身份验证模式时，ASP.NET使用Microsoft Passport的集中式身份验证服务，ASP.NET为Microsoft Passport软件开发包（SDK）所提供的功能提供了一个方便的包装（Wrapper）。此SDK必须安装在WEB服务器上。
2.1.3 窗体身份验证 这种验证方式使用客户端重定向功能，将未通过身份验证的用户转发到特定的登录窗体，要求用户输入其凭据信息（通常是用户名和密码）。这些凭据信息被验证后，系统生成一个身份验证票证（ticket）并将其返回客户端。身份验证票证可在用户的会话期间维护用户的身份标识信息，以及用户所属的角色列表（可选）。
2.1.4 None 使用这种身份验证模式，表示你不希望对用户进行验证，或是采用自定义的身份验证协议。
2.2 Enterprise Services身份验证 Enterprise Services身份验证通过使用底层的远程过程调用（RPC，Remote Procedure Call）传输结构来进行，而这种结构又使用了操作系统安全服务提供程序接口（SSPI，Security Service Provider Interface）。可以利用Kerberose或NTLM身份验证机制对Enterprise Services应用程序的客户端进行验证。
2.3 SQL Server身份验证 SQL Server可以通过Windows身份验证机制（Kerberose或NTLM），也可以通过其内置的身份验证方案-SQL身份验证机制进行验证。通常有两种可用的验证方案。
2.3.1 SQL Server and Windows 客户端可用通过SQL Server身份验证或Windows身份验证机制来连接SQL Server的某个实例。这种方式有时也被称为混合模式的身份验证。
2.3.2 Windows Only 客户端必须通过使用Windows身份验证机制来连接到SQL Server的一个实例。
3. 选择身份验证机制 设计分布式应用程序的身份验证是一项具有挑战性的任务。在应用程序开发的早期阶段，进行适当的身份验证设计有助于降低许多安全风险。 3.1 各种身份验证机制的比较 用户是否需要在服务器域中拥有Windows帐户是否支持委托是否需要Windows 2000客户端和服务器凭据是否明文传输（需要SSL）是否支持非IE浏览器 基本身份验证 是 是 否 是 是 简要身份验证 是 否 是 否 否 NTLM身份验证 是 否 否 否 否 Kerberos身份验证 是 是 是 否 否 证书身份验证 否 是 否 否 是 窗体身份验证 否 是 否 是 是 护照身份验证 否 是 否 否 是 3.2 选择身份验证机制需要考虑的因素 标识 只有当应用程序的用户具有的Windows帐户可以通过一个受信任的权威机构（它可以被应用程序Web服务器访问）来进行验证时，使用Windows身份验证机制才是合适的。
凭据管理 Windows身份验证的一个关键优势在于它可以使用操作系统进行凭据管理。当使用非Windows身份验证方式，例如窗体身份验证时，必须仔细考虑在何处以及如何保存用户凭据。其中最常用的方式是使用SQL Server数据库或是使用位于Active Directory中的User对象。
标识流动 是否需要实现一个模拟/委托模型，并将原始调用者的安全上下文在操作系统级进行跨层流动-例如，以便支持审核或针对每个用户的精细授权。
浏览器类型 应用程序的所有用户是否都拥有IE浏览器？或是你是否需要支持一个具有混合型浏览器的用户群？ 我们选择身份验证时需要根据各种方式的特点，综合考虑以上因素。

• A fresh install of Ubuntu Dapper + all the updates
• A Windows box with a fully installed and activated version of Adobe Photoshop CS2

- Fire up a terminal session and type the next commands;

TIP: Instead of using apt-get, you can install them with the Synaptic Package Manager located in the System/Administration menu

• $ sudo apt-get update
• $ sudo apt-get install wine and then type “yes”
• $ sudo wine /*To create the wine file structure*/
• $ sudo apt-get install recode and then type “yes”

- Then you need to copy all the necessary files from the Windows box;

• Copy the whole Adobe folder from “c:\Program Files\” to “/home/YOURNAME/.wine/drive_c/Program Files/”

- Now you need to export the registry keys of the Adone Photoshop CS2;

• In your Windows box, type “regedit” in the command-line and export the whole “HKEY_LOCAL_MACHINE/Software/Adobe/” to “adobe.reg”.
• The next step is to copy that file to your Ubuntu box and convert it to the encoding of YOUR system. For example, if your Ubuntu box has as default charset ascii and your Windows box has ucs-2 then “$ recode ucs-2..ascii adobe.reg” would do the trick. After you converted your adobe.reg file, type “$ sudo wine regedit adobe.reg” to import it to wine.
• That’s it! Type “$ sudo wine –winver winxp “[path to Photoshop]/photoshop.exe” or create a launcher and enjoy Adobe Photoshop CS2 on Ubuntu ;)

If you are having a problem regarding “unregistered” versions, you will need to crack your photoshop.exe file.

英语翻译网站:
http://www.readworld.com

中日英互译,还能上载翻译
http://165net.com

http://www.worldlingo.com/

http://www.netat.net/

http://www.translate.ru/eng/

日语翻译网站
1.goo 辞書:收录4部三省堂字典
http://dictionary.goo.ne.jp/index.htmlc

2.インフォシーク :支持在线翻译文本和网页
http://www.infoseek.co.jp/Honyaku/

3.@nifty翻訳:英和辞典／和英辞典 国語辞典 デジタル用語辞典
http://www.nifty.com/dictionary/?top4

4.万物大辞典:所有日常用专业辞典
http://www.prcity.co.jp/oichan/dic/index.html

5.在线字典集合网页
http://www.kyotsu.com/level2/culture/dictionary.htm

6.Bit.ex日中 中日辞書
http://www.bitex-cn.com

7.Kiki's Kanji Dictionary:日汉字发音大全
http://www.kanjidict.com/

8.楽 語 辞 書:乐器方面的辞典
http://www.cablenet.ne.jp/~atari/music09.htm

9.ライフサイエンス辞書:提供一些日文输入法的下载及电子辞典部分内容下载
http://lsd.pharm.kyoto-u.ac.jp/FTP3-dos-J.html
http://lsd.pharm.kyoto-u.ac.jp/Others-J.html

10.日语学习资源发布:日语相关的资料贴子(暴多网站)
http://bbs.online.sh.cn/elitearticle.php?elite_id=231124

11.excite翻訳:支持在线翻译文本
http://www.excite.co.jp/world/text_cn/

12.三省堂在线字典
http://www.sanseido.net/

13.カタカナ語:外来语辞典
http://homepage2.nifty.com/YONE/

14.パソコン辞典:电脑专业用语辞典
http://www.qiuyue.com/index.html

15.デジタル用語辞典:基礎的なパソコン用語から難しい専門用語まで、コンピュータに関連する用語を幅広く収録したインターネット上の用語辞典です
http://yougo.ascii24.com/

16.女の子の名前辞書
http://www.dd.iij4u.or.jp/~ume20/f_name/

17.アニメと人形劇のキャラクターのスペル辞典
http://web.kyoto-inet.or.jp/peop ... sons/animechara.htm

18.日语文章汉字假名自动全篇标注
http://www.yaru.com/

19.房英類似辞典 外来语研究辞典
http://www.awa.or.jp/home/hiroomi/b-jdic/b-jindex.htm

　　此外，附录部分的“VSS命令-权限级别对应表”是笔者整理之后的结果，有了它，大家对不同权限的用户可以使用何种功能，自会变得一目了然。

　　希望这个教程可以对并不十分熟悉VSS的开发人员和管理人员有所帮助，同时也希望可以借此机会澄清一下大家对VSS的一些“偏见”：）

1 说明

一、本教程针对不同使用对象提供Visual SourceSafe 6.0的若干使用指导，阅读对象包括Visual SourceSafe的管理员和普通用户，以及希望了解如何采用Visual SourceSafe进行软件版本控制的管理人员。管理员或普通用户在使用Visual SourceSafe的过程中，如果遇到不知如何操作，或者对某些操作的注意事项不甚了解等类似情况时，可以查阅本教程。

二、本教程的"管理员部分"是管理员必读的，如果管理员在除履行其自身职责之外，还兼任普通用户的角色，则可以参阅教程中的"普通用户部分"。作为一般的普通用户，只需阅读"普通用户部分"即可。

三、教程中列举的操作，加星号者，为高级用法（Advanced Usage），其余为基本用法（Basic Usage）。所谓基本用法是指一些通常使用频繁的，或者是使用方法较为简单的操作。所谓高级用法是指通常使用频率不多，或者较为重要的，或者用法复杂的操作。

四、本教程内容摘选并改编自Visual SourceSafe 6.0英文版联机帮助，从中提取了诸多重要信息、容易忽略的内容以及若干注意事项。一些基本内容（主要指某些基本操作的使用方法）只简单列举了条目，欲了解这些条目的详细情况请查看联机帮助的相关部分，可以通过列于这些条目之后的英文说明在联机帮助中搜索到相关内容。

五、本教程不涉及Visual SourceSafe图形用户界面操作的解释说明，对指定功能的具体操作步骤请查看联机帮助的相关部分。可以通过列于该功能之后的英文说明在联机帮助中搜索到相关内容。

六、在其他Visual Studio产品中（例如：Visual C++）可以集成Visual SourceSafe的功能，本教程不涉及有关在其他集成开发环境下如何使用Visual SourceSafe功能的内容，这部分内容主要针对普通用户。对这些内容的了解，在阅读完本教程之后，将会变得容易。此外，某些操作在Visual SourceSafe环境下使用更为方便。

2 概述

　　Visual SourceSafe（以下简称VSS）是一种版本控制管理工具。它通过将各种类型的文件（包括：文本文件、图像文件、二进制文件、声音文件、视频文件等）存入其内部数据库的方式，帮助你有效地管理工程（Project，关于VSS中工程的概念请见下面）。它允许你在多个工程间共享同一组文件；你可以将一个文件添加到数据库中，以便其他相关人员使用；任何对文件的更改将被记录下来，以便在任何时候可以恢复到该文件的某个旧版本。

　　VSS的工程组织方式使团队协作开发变得更为容易和直观。一个工程是一组存放于VSS数据库内的任意类型的文件，一个工程类似于操作系统中的目录，但VSS为其提供了版本控制、历史记录、文件合并等更多的功能支持。

3 管理员部分

3.1 维护用户列表(Maintain the User List)

3.1.1 添加用户(Add a User)

　　此处略，详细内容请查阅联机帮助。

3.1.2 更改密码(Change Passwords)

　　此处略，详细内容请查阅联机帮助。

3.1.3 创建用户列表(Create a User List)

　　此处略，详细内容请查阅联机帮助。

3.1.4 删除用户(Delete a User)

　　此处略，详细内容请查阅联机帮助。

3.1.5 编辑用户属性(Edit User Attributes)

　　此处略，详细内容请查阅联机帮助。

3.2 管理数据库(Manage the Database)

3.2.1 分析数据目录(Analyze the Data Folder)*
建议你定期备份完整的VSS数据目录（参见数据库打包）。VSS数据目录中包含有全部工程和文件的数据库信息。由于网络或操作系统的某些故障，VSS中的文件可能存在错误和不一致问题，Analyze VSS DB工具被用来查找和修复这些问题。在运行该工具前，需要锁定（Lock）所有用户并要求他们退出VSS，用户可以在一个数据库被锁定时保持文件的签出状态（参见锁定数据库）。建议分两次运行Analyze VSS DB工具，第一次修复错误，第二次核查是否仍然存在没有被修复的错误。数据目录的具体位置是由Data_Path初始化变量在SRCSAFE.INI文件中指定的（参见定制SS.INI和SRCSAFE.INI文件）。

3.2.2 数据库打包(Archive Databases)*

　　你可能需要定期地备份VSS数据库，或者数据库的某一部分。VSS Administrator工具提供了此项功能。它可以：

节省VSS数据库服务器的磁盘空间。
加快显示历史记录操作（Show History）的速度。
便于在多个VSS数据库间传递文件和工程，保持历史记录完整无缺。
备份全部或部分VSS数据库内容并压缩成文件。

3.2.3 清除临时目录(Clean Temporary Folder)

　　VSS通常在运行时把临时结果放在临时目录里，并在退出前将之删除。由于某些原因，例如非正常重启，可能导致临时内容残留在目录中。作为管理员，你有责任定期清除临时目录的内容。每隔几周一次，当没有任何用户运行VSS或VSS Administrator时，请清除临时目录的内容。临时目录的具体位置是由Temp_Path初始化变量在SRCSAFE.INI文件中指定的（参见定制SS.INI和SRCSAFE.INI文件）。

3.2.4 锁定数据库(Lock a Database)

　　数据库锁定功能将不会自动锁定那些当前已经登录的用户，你应该在锁定数据库之前要求登录用户退出VSS。在重新允许用户使用VSS之前，需要解除对数据库的锁定。


3.2.5 数据库恢复(Restore Databases)

　　此处略，详细内容请查阅联机帮助。

3.2.6 使用多个数据库(Work with Multiple Databases)*

　　缺省时，VSS将所有文件集中放在一个数据库中。如果可能，应尽量使用一个数据库存放所有文件，这比分多个数据库存放要好，因为：
你不能在多个数据库间共享（Share）文件（参见对文件和工程的Branch/Share操作）。
将位于多个数据库中的内容集中在一起是比较困难的，需要使用VSS Administrator的Archive功能（参见数据库打包）。
出于安全的考虑，VSS的用户信息，包括密码在内，是和数据一起存放的。
如果为了安全起见，要将信息拆分成多个独立的数据库，

　　缺省时，VSS将所有文件集中放在一个数据库中。如果可能，应尽量使用一个数据库存放所有文件，这比分多个数据库存放要好，因为：你不能在多个数据库间共享（Share ）文件（参见对文件和工程的Branch/Share操作）。
将位于多个数据库中的内容集中在一起是比较困难的，需要使用VSS Administrator 的Archive功能（参见数据库打包）。
出于安全的考虑，VSS的用户信息，包括密码在内，是和数据一起存放的。如果为了安全起见，要将信息拆分成多个独立的数据库，这种信息存储方式将带来极大的便利,但你必须为每个数据库都单独添加用户。


3.3 有关权限的话题(About Rights)

3.3.1 权限的传递(Rights Propagation)

　　当你添加了一个新用户，并为该用户设置了针对某个工程的权限时，将在VSS数据库中建立起一个assignment。该 assignment将会沿着工程树向下传递直至遇到另一个assignment。

　　例如：针对工程"$/" ，你为用户A指定了Add权限（参见安全访问权限），而对于工程"$/Sample"，你没有为用户显式指定权限，则该用户将对工程"$/Sample"自动拥有Add权限。当你在工程"$/Sample/BusinessObject"处为其指定了Read权限后，将阻止早先assignment的向下传递过程，所以用户A对该工程（指"$/Sample/BusinessObject"）及其子工程都只具有Read权限了。

　　当你首次添加一个用户时，该用户在工程"$/"处被赋予的权限由"缺省权限"决定，缺省权限是通过在VSS Administrator里设置Project Security属性页的内容来定义的。你可以通过修改该页内容，全局性地变更所有用户的缺省权限。

3.3.2 安全访问权限(Security Access Rights)

3.3.2.1 缺省安全设置

　　当安装VSS后，缺省安全设置将被启用。你可以利用定制的方式，使某些用户拥有对某些工程和某些VSS命令的特定权限。

　　缺省安全设置很简单，当添加新用户时，你只有两种级别的访问权限可供选择：

只读权限（Read-only rights）：用户可以查看VSS中的任何内容，但不能更改。
可读写权限（Read/write rights）：用户可以查看和修改VSS中的任何内容。

　　如果这样的访问权限级别足以应对日常使用，那么就无需再增强安全控制的级别了。

　　所有的VSS安全管理都在VSS Administrator中进行。任何能运行该程序的用户都可以改变VSS的任意特性，所以最好只有管理员才使用该程序。

3.3.2.2 更高级别的安全控制

　　在VSS中，对工程的安全性控制，是通过制定用户访问权限来实现的。每个工程仅能被那些具有相应权限的用户访问到，每个命令仅能被那些具有相应权限的用户使用。可以通过VSS Administrator来定制权限，以达到更高级别的安全控制。

　　以下是VSS的权限级别列表，下列每种权限都拥有该权限之前的全部权限。例如：拥有Check Out权限的用户，也将同时拥有Read权限。（参见附录A2：VSS中部分命令的对应权限级别）

权限 描述
Read (R) 类似于缺省安全设置中的只读权限
Check Out (C) 可以使用Check Out/Check In/Undo Check Out等命令对文件进行修改
Add (A) 可以使用Add/Delete/Label/Rename等命令对文件进行修改
Destroy(D) 可以使用 Destroy/Purge/Rollback等命令对文件实施永久删除操作

4 普通用户部分

4.1 对工程、文件的一般性使用(Normal Use about Projects and Files)

4.1.1 打开/关闭数据库(Open/Close a Database)

　　此处略，详细内容请查阅联机帮助。

4.1.2 创建新工程(Create New Projects)

　　此处略，详细内容请查阅联机帮助。

4.1.3 添加文件、目录、工程(Add Files，Folders，and Projects)

　　此处略，详细内容请查阅联机帮助。

4.1.4 删除和恢复文件、工程(Delete and Recover Files and Projects)

　　VSS提供了3种删除文件的方法：

• Delete：VSS只把指定文件从当前工程中删除，而在VSS数据库中仍留有该文件的记录。此外，其他共享了该文件的工程仍保留此文件（参见对文件和工程的Branch/Share操作）。
• Destroy：VSS将把指定文件从VSS数据库中彻底删除，其后将无法恢复。
• Purge：永久性删除已被Delete掉的文件，其后将无法恢复。

　　对于共享文件，Delete和Destroy仅将文件从当前所选工程中删除掉，其他共享了该文件的工程，以及VSS数据库中，仍留有此文件。

4.1.5 移动文件和工程(Move Files and Projects)

　　移动一个文件的唯一方法是，在文件新所在位置的上一级工程（parent project）处使该文件共享（参见对文件和工程的Branch/Share操作），然后将原有工程（original project）下的该文件Delete或者 Destroy（参见删除和恢复文件、工程）。移动后，文件的历史记录将被保留。

　　通过使用Move命令，你可以将一个子工程（subproject）从某个上级工程重置到另一个工程下。该操作不会改变子工程的内容和历史记录，但它会影响上级工程的历史记录（包括子工程所在的原有上级工程和新的上级工程）。当移动一个工程后，你将无法重建原有上级工程的某个旧版本。

4.1.6 重命名文件、工程(Rename Files or Projects)

　　若某个文件被多个工程所共享，对该文件的重命名将影响所有工程，而在Branch状态下，则不影响（参见对文件和工程的Branch/Share操作）。

4.1.7 设置工作目录(Set Working Folders)

　　此处略，详细内容请查阅联机帮助。

4.2 签入、签出、获取、查看及相关操作(Check In/Out、Get、View and Other Related Use)

4.2.1 签入签出操作(Check In and Check Out Files)

　　此处略，详细内容请查阅联机帮助。

4.2.2 撤销签出(Undo Check Out)

　　执行该操作时，若用户选择了替换本地文件，则用户将丢失最近一次签出后对该文件在本地的更改。

4.2.3 获取最近版本(Get Latest Version)

　　此处略，详细内容请查阅联机帮助。

4.2.4 获取早期版本(Get Earlier Version)

　　此处略，详细内容请查阅联机帮助。

4.2.5 获取和查看文件、工程(Get and View Files and Projects)

　　Get操作将文件或工程拷贝至本地的工作目录，并设置为read-only属性。可以用View操作查看文件内容，此时用户无需设置工作目录。

　　尽量不要删除vssver.scc文件。本地工作目录及每个子目录下都包含一个这样的文件，VSS利用其中记录的信息确定本地目录中哪个文件已经更改了。删除后，将使新一次的Get操作速度减慢。

4.2.6 回滚到以前版本(Rollback to Previous Versions)

　　该操作将使文件的内容恢复到先前某个版本时的状态，它将使所有在该版本后所做的改动丢失。如果你所回滚的文件被多个工程共享，则操作只影响你所指定的那个工程，并且它会自动实行Branch操作（参见对文件和工程的 Branch/Share操作）。建议你使用虚拟回滚（Virtual Rollback），它将不会使随后的改动永久丢失。具体操作如下：

• 选择你要回滚的文件并签出
• 使用Get命令获取某个原有版本到本地
• 签入该文件

4.2.7 多人同时签出一个文件(Check Out Multiple Files) *

　　缺省状态下，一个文件只允许一个人签出，管理员可以通过修改配置，允许多人同时签出。此时，VSS将跟踪所有签出该文件的用户。每当用户签入时，VSS都将和当前存于数据库内的最新版本进行比较，若用户修改的是同一文件的不同处，VSS将进行简单的合并（Merge），否则提示用户，并且不允许签入。用户可以通过VSS提供的Visual Merge工具，比较存放于VSS数据库中的文件和本地文件的异同，手工修改本地文件，直到认为已经可以签入时，方才执行最终签入操作。（参见合并）

4.2.8 合并(Merge)*

　　在VSS中，合并可能发生在3种场合下：使用Multiple Checkout的工作方式；合并原先已经Branch了的文件；获取（Get）文件。

• Multiple Checkout：若多个用户同时签出一个文件，第一个用户只要简单的签入就可以了。后续用户也可以签入，但他们的更改将需要和其他所有用户的更改合并，VSS将得到完整的更改内容（参见多人同时签出一个文件 ）。
• Branch：当被Branch的文件合并到其中一个分支时，VSS将会把在另一个分支上所做的改动合并到该分支上（参见对文件和工程的Branch/Share操作）。
• Merge on Get：在Multiple Checkout工作方式下，当使用Get Latest Version操作时可能引发合并操作，此时保存在VSS数据库中的内容将合并到本地文件。但如果某个文件是排他性签出的，则不会引发合并操作（参见排他性签出 ）。

　　在完成一个合并之后，VSS遵循如下规则：

• 如果仍有冲突，VSS维持文件的签出状态，为了使文件能顺利签入，你必须排除这些冲突。
• 如果你使用Merge Branches命令，将一个文件合并到一个工程中，而该工程中的对应文件已被签出，该文件将继续保持签出状态（参见对文件和工程的Branch/Share操作）。
• 在任何其他时候，VSS将会提示你，或者在合并后自动签入，或者保持文件的签出状态以使你在更新VSS数据库中内容之前再核查一边。

　　缺省情况下，当发生冲突时，VSS将启用其Visual Merge工具。

4.2.9 排他性签出(Exclusive Check Out)*

　　允许多人同时签出一个文件是针对整个VSS数据库而言的，但用户仍可以根据实际情况，针对某些文件修改该规则。对某个文件实施排他性签出，则其他用户将无法签出该文件，直至该用户使用了签入操作。

4.2.10 对工程的Cloak操作(Cloak Projects)*

　　若对某工程实行了Cloak操作，则当对该工程的上一级工程进行Get/Check In/Check Out/Undo Check Out/Project Difference操作时，将不会影响该工程及其子工程。而在该工程上进行类似操作时，则和平常得到的结果一样。这一属性将传递给其下的子工程。

　　例如：某个工程其路径为$/Application，下面有三个子工程：$/Application/Code，$/Application/Test，$/Application/Docs，而 Docs工程下的内容可能对你没有任何用处。当你每次从$/Application处进行Get操作后，都需要从本地删除多余的Docs目录。此时可以对Docs 进行Cloak操作。这样，每次的Get操作将只把Code和Test下的内容放到本地。如果你需要获取Docs工程下的内容，则可以单独从Docs处进行Get 操作。

4.3 Branch、Share、Label和Pin操作(Branch、Share、Label and Pin)

4.3.1 对文件和工程的Branch/Share操作(Branch and Share Files and Projects) *

　　在VSS中，通过Share操作，一个文件可以被多个工程共享，在任何一个工程中对该文件的更改，都将反映到其他相关工程里。

　　Branch操作则消除这种共享，每次将一个被共享的文件拆成两个分支，在不同工程中分别跟踪该文件。通过查看文件属性的Links属性页可以了解该文件被哪些工程共享，通过查看Paths属性页可以了解文件的分支状况。

　　例如：产品目前的正式版本为2.0（工程路径为$/Application），在加入新功能后将升级为3.0。但在开始升级的过程中，其间的一个过渡版本2.1存在bug，需要修改。此时可以进行如下操作：选择被Label标识为2.0的那个版本（参见给文件、工程指定标签），利用Share功能创建过渡版本（工程路径为$/Application2.1），此时两个工程中的文件是共享的，且$/Application2.1中的所有文件都处于Pin状态（参见 Pin操作） ，即：在向3.0升级的过程中，对$/Application中相关文件的更改，将不影响$/Application2.1下的内容，但此时文件仍是共享的。仅对需要修改bug的文件采取Branch操作。这样做的好处是，中间版本的bug修改工作和3.0的升级工作可以同时进行，并且最大限度的降低了所需的存储空间。

4.3.2 给文件、工程指定标签(Label Files and Projects) *

　　VSS使用3种方式跟踪文件的历史记录：内部版本号，日期，用户自定义标签。

　　标签可以是一个不超过31个字符长度的串，例如："1.0"、"2.01b"、"Final Beta"、"Approved for QA"。应用Label功能，用户就可以获取某个特定时期的软件内容了。所有当前工程下的文件和子工程都将继承该标签。

　　注意下面几点：

• 当使用Label功能时，表明你在所选工程的历史记录里创建了一个新的版本，但文件和工程本身的内容并未发生变化。
• 对某个工程的某个标签再次使用Label操作将覆盖原来的标签内容。

　　请参见附录A1：同时维护一个工程的多个版本

4.3.3 Pin操作(Pin)*

　　该功能对共享文件很有用，尽管它的使用不仅限于共享文件，也包括其他任何文件。当你对一个文件实施Pin操作后，你将不能对之做任何修改。如果一个文件在Pin之后又被实施了Share操作，而被Pin的那个版本同时也是被共享的版本，则所有共享该文件的工程都不能更改该文件。如果一个文件先被实施了Share操作，而后在某个工程中被Pin了，则除了这个工程外的其余工程仍可以更改该文件（参见对文件和工程的Branch/Share操作）。

4.4 其他操作(Other Use)

4.4.1 扩展关键字(Expand Keywords)*

　　VSS可以将某些指定信息（例如：VSS内部版本号）直接插入文本文件中。用户只要将某些关键字放入文件的注释中，每次添加（Add）或签入（Check In）文件时，VSS都会自动查找这些关键字，并将相关信息置于其后。

　　VSS中常用的关键字：

　　例如：

　　在某文件中加入如下一行：

　　$Revision: $

　　若当前该文件在VSS内部的版本号是22，则签入后VSS会将之修改为：

　　$Revision: 23 $

4.4.2 使用Shadow目录(Work with Shadow Folders)*

　　Shadow目录位于服务器端，包含了工程中所有的文件。这些文件既非位于VSS数据库中的master copy，亦非位于本地工作目录的local copy，而是最近一次签入的所有内容。Shadow目录应该由管理员来设置。

　　是否使用Shadow目录功能是可选的，通常在如下两种情况下可以考虑使用该功能：

• 为使某些用户能查看文件（但不能更改），这些用户可能没有对VSS的访问权限。
• 不让你的本地工作目录保留可编译的软件副本。为使每个用户都能得到一个最新版本的软件，所有用户可能希望在某个目录下集中进行编译，而非在各自的工作目录下编译。在这种情况下，Shadow目录功能通常和添加（Add）、签入（Check In）之后的Remove Local Copy结合使用。

　　Shadow目录不会跟踪子工程的变化，例如：你有一个被Shadow的工程$/A，包含两个子工程：$/A/1和$/A/2，而你又将$/A/2重命名为 $/A/B，这种变化将不会被反映到Shadow目录中。你可以手工修改，或者利用Reconcile All功能，使之保持同步。

4.4.3 性能优化(Optimize Performance)*

　　有两种方法可以改善VSS的性能：尽可能多的将内容通过网络拷贝至本地来做；修改初始化文件对VSS的性能进行微调。

　　具体优化措施：

• 在SS.INI或SRCSAFE.INI文件中设置如下变量：

  Diff_Ignore (PC) = c-e-s-w-

  使VSS在进行文件比较时忽略end-of-line标记，从而加快运行效率

  CP_OnSelection = No

  在使用VSS Explorer时，缺省状态下，用户使用鼠标单击或使用键盘的方向键在工程列表上移动时，就会选中工程。设为No后，只有双击鼠标或按回车键才会选中。

• 设置临时目录

  缺省情况下，VSS将临时文件存于服务器端，但管理员可以通过修改SS.INI中的Temp_Path变量，将临时路径设置在本地。

• 让管理员在SRCSAFE.INI文件中将Lock_Mode变量设置为Native

  这是SRCSAFE.INI中该变量的缺省设置，把该变量设置为Native将使几乎所有的VSS操作都得到加速。该变量只能由管理员来设置。

• 管理员通过Disable下面的功能，也可以一定程度地改善性能：
  • Shadow folders（参见使用Shadow目录）
  • Journal files
  • Project security system（参见安全访问权限）
  • Keyword expansion（参见扩展关键字）

4.4.4 查找文件(Search for Files)

　　VSS Explore的list view缺省时只显示当前工程中的所有文件。通过使用Search命令，可以只显示符合指定要求的文件。例如：只显示 .h文件，只现实被签出的文件。Search命令是允许递归的。

4.4.5 设置密码(Set Passwords)

　　如果VSS管理员指定域账号为VSS登录账号，则用户登录VSS时将不会提示输入密码。

4.4.6 编写批处理文件(Writing Batch Files)*

　　在编写批处理文件时，一些在命令行方式下使用的交互手段需要改变。

• 屏蔽输入（Disable Input）

  如果你的批处理文件中包含了一系列VSS命令（它们可能需要整夜运行），你一定不希望程序执行期间会停下来提示用户输入信息。有3个命令行选项可以解决此类问题。

  缺省时，VSS在执行诸如添加（Add）、签入（Check In）等操作时会提示你输入注释（Comment），利用-c选项可以避免该类提示：

  命令	描述
  -c-	不添加注释
  "-cHello"	使用Hello字串作为注释
  -c@COMMENT.TXT	使用comment.txt文件的内容作为注释

  此外，VSS通常会要求用户回答yes或no，你可以使用-i选项避免此类问题：

  命令	描述
  -i-y	对所有此类提问自动回答Yes
  -i-n	对所有此类提问自动回答No
  -i	使用缺省回答

  VSS也可能会提示登录名，你可以使用-y选项提供足够多的信息。

• 重定向输出

  缺省时，VSS将所有输出定向到屏幕，在命令行状态下你可以使用-o选项分页输出，而在批处理文件中你同样可以利用-o屏蔽输出或重定向输出。

  命令	描述
  -o-	屏蔽输出
  -oRESULTS.TXT	重定向所有输出到文本文件results.txt中，如果该文件已存在，输出内容将追加到该文件末尾。

• 使用命令行返回值

  在命令行状态下运行VSS时，VSS会设置一些返回值来标明运行状态。你可以在批处理文件中根据VSS的返回值采取相应措施。

  返回值	描述
  100	表明出错，例如：VSS无法找到数据库文件，或者你试图签出某个早已被签出的文件。
  1	表明一个不是很严重的错误，将在如下三种情况下发生： 当你使用ss Dir时，没有找到任何条目。 当你使用ss Status时，至少有一项被签出。 当你使用ss Diff时，至少有一个文件不一致。 所有这些情况表明，即使本次操作是成功的，你执行的下一个VSS命令也可能操作失败。
  0	VSS成功执行。

4.4.7 定制SS.INI和SRCSAFE.INI文件(Customize the SS.INI and SRCSAFE.INI Files)

　　VSS有两类初始化文件，它们包含了VSS的一些环境变量：SS.INI，每个用户都有一个这样的文件；SRCSAFE.INI，仅有一个，定义了VSS 的一些全局变量，只有管理员才有权修改它。

附录  同时维护一个工程的多个版本(Maintain Multiple Versions of a Project)

　　你可以使用Share/Pin/Branch的方式，也可以使用Label方式。如果你所处的环境只要求少量的改动，比如：轻量级的patch，使用 Label比较合适；如果你正在规划大量的开发内容，使用Share/Pin/Branch比较合适。例如：在软件处于Beta版时，你可以通过Label功能冻结（freeze）之，并同时修改Beta版的bug。当你正同时维护着某个产品的1.1版和2.0版时，合理的做法是，为每个版本创建一个新的工程， Share并Pin所有的文件，在需要的时候Branch。当1.1发布时，你可以将1.1版的工程Label，而后将对1.1版的改动重新Merge到2.0版中。下面的几个场景为你使用Label功能提供指导：

场景1：理想情况

1、对即将到达Beta 1版的工程进行开发和测试。
2、当你认为时机适宜时，将之Label为"Beta 1"。
3、开始Beta 2版的工作。

场景2：文件A的某个版本被错误地包含在Beta 1版中

1、对即将到达Beta 1版的工程进行开发和测试。
2、当你认为时机适宜时，将之Label为"Beta 1"。
3、开始Beta 2版的工作。
4、如果发现文件A某一时期的版本被错误的包含在了Beta 1版中，选择该文件的正确版本并Label为"Beta 1"。
5、获取（Get）Beta 1 版的工程。

场景3：需将bug-fix后的文件A被包含在Beta 1版中，而其余文件未曾改动

1、对即将到达Beta 1版的工程进行开发和测试。
2、当你认为时机适宜时，将之Label为"Beta 1"。
3、开始Beta 2版的工作。
4、你发现，包含在Beta 1版中文件A的那个版本存在bug，必须改正，而工程中的其余文件则不须改动。
5、签出该文件，改正，然后签入。
6、将工程重新Lable为"Beta 1"（你将被询问是否确认删除原有标记）。

场景4：需将bug-fix后的文件A包含在Beta 1版中，而其余文件也作了改动

1、对即将到达Beta 1版的工程进行开发和测试。
2、当你认为时机适宜时，将之Label为"Beta 1"。
3、开始Beta 2版的工作。
4、你发现，包含在Beta 1版中文件A的那个版本存在bug，必须改正，而工程中的其余文件已经改动过且已经被签入。
5、签出该文件，改正，然后签入（此时该文件的VSS内部版本号将自动加1）。
6、将该文件Label为"Beta 1"（和工程的Label同名），这将使该文件的现有版本被指定为"Beta 1"。

场景5：文件A的一个原有版本需要进行bug-fix，并加入Beta 1版中

1、对即将到达Beta 1版的工程进行开发和测试。
2、当你认为时机适宜时，将之Label为"Beta 1"。
3、开始Beta 2版的工作。
4、你发现，包含在Beta 1版中文件A的那个版本存在bug，必须改正。例如：文件的当前内部版本号是6，且包含了为达到Beta 2版所做的某些改动，而你不希望将这些改动并入Beta 1版中。
5、签出文件A（Version 6）
6、获取Version 4，覆盖Version 6的本地版本。
7、修改该文件Beta 1版中的bug，然后签入。这将使文件A的内部版本号升至7（Version 4的内容加上bug-fix后的内容，但没有包含 Version 5和Version 6的内容）
8、将Version 7 Label为"Beta 1"。这将使文件A的Version 7版被指定为"Beta 1"。现在，如果你尝试获取Beta 1版的工程时，你将会得到包含bug-fix后的文件A（被单独Label）连同原来Label为"Beta 1"的工程中的其余文件。
9、为了继续 Beta 2版的工作，需要恢复在Version 5和Version 6上的改动，再次签出文件A（Version 7）
10、获取Version 6。
11、覆盖Version 7的本地版本，或合并之（这将使本地版本变成Version 6的内容加上你在Version 7中为"Beta 1"所做的bug-fix）。
12、继续修改文件A的本地版本直到你满意，然后签入。这将产生文件A的Version 8，现在你将可以继续Beta 2版的工作了。

附表 VSS中部分命令的对应权限级别

下表中打星号表示具有该类权限的用户可以使用该命令。

[1] 此处指用户必须有对Parent Project的A类权限。
[2] 此处指用户必须有对目的Project的C类权限，同时有对原Project的R类权限。
[3] 此处指用户必须有对目的Parent Project的A类权限，同时有对原Parent Project的D类权限。
[4] 此处指用户必须有对原 Project的C类权限，同时有对目的Project的A类权限。

如需复制、传播，请附上本声明，谢谢。原文出处：http://morningspace.51.net/， moyingzz@etang.com

Session（会话）接口是Hibernate应用使用的主要接口。会话接口的实例是轻量级的并且创建与销毁的代价也不昂贵。这很重要因为你的应用可能始终在创建与销毁会话，可能每一次请求都会如此。Hibernate会话并不是线程安全的因此应该被设计为每次只能在一个线程中使用。

Hibernate会话是一个介于连接和事务之间的概念。你可以简单地认为会话是对于一个单独的工作单元已装载对象的缓存或集合。Hibernate可以检测到这个工作单元中对象的改变。我们有时也将会话称为持续性管理器，因为它也是与持续性有关的操作例如存储和取出对象的接口。注意，Hibernate会话与Web层的HttpSession没有任何关系。当我们在本书中使用会话时，我们指的是Hibernate会话。为了区别，有时我们将HttpSession对象称为用户会话。

SessionFactory接口

应用从SessionFactory（会话工厂）里获得会话实例。与会话接口相比，这个对象不够令人兴奋。

会话工厂当然不是轻量级的！它打算在多个应用线程间进行共享。典型地，整个应用只有唯一的一个会话工厂——例如在应用初始化时被创建。然而，如果你的应用使用Hibernate访问多个数据库，你需要对每一个数据库使用一个会话工厂。

The cost impact to a company of a failed project can be severe indeed. The impact on the reputation of the project manager can be disastrous.

Software project management is not easy, and it requires considerable skill to successfully manage the many different risks that conspire to de-rail a project:

Numerous methodologies are available for mitigating these risks – PRINCE2, RUP, DSDN, eXtreme programming – and these have helped to some extent.

This document introduces the 3D™ methodology – a set of best practices and quality tools developed by BuildMonkey, which can be summarised as.

De-risk. Deploy. Deliver.

In any software project, deployment is a milestone on the project plan that is usually associated with payment – or staged payment. Through the course of development, any number of problems can arise to derail efforts to reach this milestone.

The 3D™ methodology and supporting toolset is based on many years of experience at the sharp end of projects, understanding what has worked and what has not, and the lessons learned from each.

Competent practitioners, and experienced project staff, will find resonance with many of the contents of this document and may find themselves saying “this is just common sense”. This is certainly true, but the main problem with common sense is that it is not as common as people think it is.

This document, and the 3D™ methodology, is an attempt to bring that common sense together in a single location, as a coherent set of best practices supported by proven tools to help you to release on-time, on-budget, with no defects.

The Problem To Be Solved

No methodology has yet focused on the component that all development projects share – the build.

One of the reasons for this is that the term “build” is interpreted differently by different people:

• The development team sees it as compilation and assembly;
• The integration team see it as the bringing together of all of the components in the application in a format suitable for release;
• The deployment team see it as something which produces the artifacts that they have to install and configure;
• The testing team see it as something which produces the artifacts that they have to test;
• The Project Manager sees it as an opaque step that nobody is entirely responsible for;;
• The end customer should not see it at all;

The BuildMonkey view is that the build is the combination of processes and technology that take software from design to deployment – _where the return on investment starts to be seen.

It is clear that a methodology is required to de-risk development projects and to standardise use of the term “Build Management”.

Best Practice: “Build Management” encompasses everything from compilation, all the way through to release to the customer.

No Release, No Revenue

Any Finance Director knows that development is just an activity that needs to be tolerated in order to produce something that will deliver a return on investment.

It may sound strange, but a large number of software developers do not appreciate and embrace this basic truth. This is in part due to their closeness to the application being constructed.

A common problem faced by development projects is therefore that it is the software developers who manage the build. This creates a situation where the build is focused on the needs of development, and is not geared towards releasing the output of coding such that business value can be realised.

Build Management should therefore focus on the end result of development – a return on investment – and ensure that all of the inputs to the process are incorporated in pursuit of this goal:

Best Practice: Focus on the end, and accommodate the inputs

Software Tools Are Only Part of the Answer

Software projects are a complex set of interdependent people and teams and can be likened to a convoy of ships. A convoy has to move at the rate of the slowest ship. Increasing the speed of a single ship in the convoy will not increase the speed of the convoy – it will simply increase the amount of wasted capacity in the speeded-up ship.

Speeding up the slowest ship will, however, have a positive effect since the whole convoy can now move faster.

Many Project Managers try to improve productivity by implementing some degree of automation in development projects – particularly in the area of the build – and often purchase “magic bullet” build software that provides this.

Simply using automated build software does not improve productivity any more than the example above improves convoy speed - as it only increases the speed of a single ship in the convoy.

There is no point in speeding up development, if the target production infrastructure cannot keep pace – this just increases the inefficiency. A lot of organisations make this mistake – highly agile development processes trying to feed into considerably less agile deployment processes. The result is inefficiency, waste and over-run.

Before considering using an automated build tool it is essential to ensure that the inputs to, and outputs from, the build can cope with the improved build speed. It is imperative to ensure that the processes and technology employed are geared towards taking the project to a successful conclusion – on-time and on-budget.

Best Practice: Don’t rely on software tools alone, they may solve symptoms whilst creating problems elsewhere

Configuration Management Best Practices

Software Configuration Management (SCM) is a relatively mature discipline with much written about methodologies and techniques, and these will not be recreated here.

We will focus instead on leveraging the SCM repository, and the facilities that it offers, to further the goals of the project rather than to consider SCM in its own right.

It All Starts Here

The SCM repository - how it is managed and used – is the keystone of good build management and successful delivery of projects.

The SCM repository is the slave of the project, not the other way round. It should be solid and reliable, yet flexible enough to accommodate the needs of new projects. Project Managers should not have to retrofit their planning to accommodate an inflexible SCM setup.

If used correctly, the SCM repository will enhance productivity, and minimize risk, through being able to provide exactly what the project – and project management – require. If used incorrectly, it can cause delay and slippage through having to do things inefficiently further down the chain.

Best Practice: The SCM repository is the slave of the project, not the other way round.

Configuration Management is not Version Control

Most software developers regard the SCM repository as a massive storage area where they simply check versions in and out – a common cause of problems.

Simply checking things into an SCM repository is not Configuration Management any more than karaoke is opera.

A well-maintained SCM repository is so much more than version control, and should provide:

• The ability to recreate any identified baseline, at any time;
• Meaningful statistics on what is changing, when and by whom;
• Management information, such as “how many new defects were introduced by the refactoring of component ‘X’?”

In order to be truly effective in a project, the SCM repository should store all of the artifacts that form part of a baseline or a release.

Most development projects simply store the code that is being developed and their use of the SCM repository is no more sophisticated than this.

Most applications nowadays are not just source code. Take the example of a modern computer game – the vast majority of the code base is made up of artifacts other than code such as audio clips, pictures and movie clips.

Where an application relies on a database this database will have a schema and structure that may change from release to release – this schema must be captured.

There will normally also be seed data for the database which should be considered as part of the baseline.

In a large distributed application, the software being developed will sit atop a number of pieces of software (e.g. application servers, web servers and message queues).

The configuration of these underlying applications have an effect on the quality – or otherwise – of the software being developed and should, therefore, be considered part of the baseline for a release.

The underlying environment and infrastructure is a key component of the project, particularly in the case of distributed applications.

Such banal considerations as DNS zone files, user account information and system parameters have to be considered as some of the moving parts which affect the application and therefore be placed under configuration control.

This is of particular importance when there is more than one environment involved in the project (e.g. a development environment and a separate test environment) since the question of “are these environments the same?” crops up again and again.

Best Practice: Everything that can be changed, and affect the behaviour of the application, is a candidate for configuration control

The Point of Labelling

It is a common misconception that simply applying labels, or tags, to the SCM repository creates a baseline but this is only partly true without corresponding records of:

• What label has been applied;
• When that label has been applied;
• Why it has been applied (i.e. what milestone, or other external event, the label is associated with);

The use of a naming convention for labels can deceive even further. For example, a project that uses a date-based labeling convention (dd_mm_yyyy) will have several labels of the form (03_05_2004, or 09_06_2004) and will reasonably assume that they have some kind of record of the baseline on those dates.

But what was happening in the project on those dates? Was the 03_05_2004 label applied immediately before a release to test, or immediately after?

Best Practice: Labels should be used to identify and inform about events in the project

This may seem like stating the obvious, but there should be a reason for a label being applied – the whole purpose of labeling is to identify some event in the development cycle that may need to be re-visited.

To this end, labels can be divided into two categories:

• Point-in-time
  Associates particular versions with a particular calendar date, or other event that is fixed in time (e.g. MONTH_END_JAN_2004, or RELEASE_1_0_1);
• Point-in-process
  Associates particular versions with events in the project that may recur at a later stage (e.g. LATEST_RELEASE, or CURRENTLY_IN_UAT);

Best Practice: Every label should have a point, whether point-in-time or point-in-process

Management Information

The job of the Project Manager, ultimately, is to bring the project to a successful conclusion. If this were an easy task that happened by default, then there would be no need for a Project Manager.

In order to be able to do this job well, a Project Manager needs information. He needs to know what is going on in the project – who is doing what, who is working on which components, and a wealth of information can be obtained from a well-managed SCM repository:

• What is changing in the environment – what has changed since a given point in time or how often particular elements are changing;
• Who is changing things in the environment;
• Why things are changing in the environment;

Of course, the final item in the list requires that committers are using descriptive comments to indicate why they are marking a particular change. A well-managed SCM repository should enforce this.

Best Practice: The SCM repository should provide meaningful, and accessible, management information

Build Best Practices

As explained at the beginning of this document, the term “build” means different things to different people. The most common interpretation is the one used by developers, where the term “build” describes the compilation and assembly step of their development activities but this narrow interpretation is a common cause of problems and over-runs, on development projects.

Building is not Compiling

At the outset of the project, the Project Manager will ask the question “how long to set up the build?” and a developer – thinking of compilation and assembly – will answer something like “1 day” – a task and duration which is then duly marked on the project plan and development begins.

Later in the project, when it is time to start deploying and testing the application, this “build” needs to be refactored to accommodate the deployment and test tasks. In doing so, it turns out that the way the application is being assembled is not conducive to it being deployed or tested correctly – so the compilation and assembly staged need to be refactored as well.

In the meantime, the development team sits on its hands whilst the “build” is refactored to accommodate the needs of the project – valuable time is lost whilst the deadline continues to advance.

Best Practice: Know what will be required of the build before starting to write the scripts

Don’t Throw Out The Baby With The Bathwater

From a build perspective, projects with similar architecture (both in terms of the team and the application) will have similar attributes. There will obviously be some changes required, but these will tend to follow the 80/20 rule to a large degree.

For example, a web application that is being developed by an in-house team and that will be deployed to a Tomcat servlet container and Oracle database will follow largely the same steps and require largely the same deployable artifacts.

A good SCM repository will enable the latest versions of boiler-plate build scripts for such an application to be found. These can be used almost off-the-shelf – meaning that development can start apace without having to wait on the build to be constructed for similar applications .

Best Practice: Well-crafted builds are re-usable and should be re-used

The Architecture Drives The Build<

Following on from the previous section, it should be clear that the architecture of what is being developed – and the structure of the team(s) developing it – will dictate how the build should look.

There is little value to be gained in trying to retrofit build scripts for a computer game (developed by 12 people all in the same room) into a project to produce a large J2EE application with development occurring at six different sites around the world.

Best Practice: Well-crafted builds are flexible, but a “one-size-fits-all” approach can be costly

Management Information

There are a number of people who need information that the build can provide:

• The Project Manager needs to track overall progress against defined milestones – number of outstanding defects, whether a committed release date will be met etc;
• Development leads need to be sure that the code is of the quality that they require – test reports, bug analysis patterns, code metrics, document and UML generation etc;
• The deployment team need to know that the artifacts will work in their target environment, and that the environment is as the application expects it to be. They also need to know whether two (or more) environments are “the same”;
• The test team need to have confidence that they are testing against a known baseline, and whether defects that they see have been rectified in development (or whether they are re-appearing after already being fixed);
• Everybody needs to be able to communicate effectively using the same language, and have a common terminology for release versions – particularly if there are multiple threads of development;

A good build infrastructure will provide all of the above information, and more besides.

Best Practice: The build should tell all project participants what they need to know

Deployment Best Practices

Considering that it is generally an important milestone on a project plan, normally resulting in payment or a staged payment, deployment is one of the most overlooked areas of software development.

The normal course of events is:

1. Release artifacts are created;
2. Some installation and release notes are cobbled together in the form of a README;
3. The deployment team work frantically to install and configure the application – the testing team (or, worse still, the customer) are idle and unproductive in the meantime;
4. Some symptoms are found which are suspected to be application defects;
5. The development team blame the environment;
6. The deployment team blame the application;
7. Repeat (5) and (6) ad nauseam.

When a documentation team are also considered - responsible for creating documentation that the end user will need to install, configure and use the application – the situation becomes even more difficult.

This situation can be avoided by planning for deployment from the beginning. Deployment is an inevitable part of software development, yet it always seems to take people by surprise.

Best Practice: Know that deployment is inevitable, and incorporate it into the automated processes

Deployment Is Not Installation

As part of normal development activities, artifacts are installed into sandbox environments – and test environments – many times. But this is not deployment, this is installation.

In order to get an application into its production environment, be that an internal environment or on hosted-infrastructure, a number of hurdles must be overcome:

• The application must pass UAT;
• The application must be installed and configured correctly:
• All pre-requisites for the application must be satisfied;
• The end customer must accept the handover;

Deployment is that point in the life of an application where it starts to produce a return on investment. “Launch”, “Go-live”, “Release”, “First Customer Shipment” are all phrases which describe the same event.

Best Practice: Deployment is the point where an application starts to provide a return on the development investment.

The Environment Is a Refactorable Component

This point cannot be stressed enough, particularly in large distributed applications.

Every application, large or small, has a runtime environment in which it operates. In a simple desktop application, this is a standalone machine (such as a PC). In larger applications, this will be a combination of machines (e.g. an application server and a database) operating together to provide the runtime environment.

In either case, the application expects certain facilities to be available from the runtime environment and will function incorrectly – or cease to function – if these are not present .

The environment itself, whether standalone or a network, contains many moving parts that can be independently configured. IP addresses, or hostnames, can be changed. User privileges can be modified or revoked. Files and directories can be removed. Each of these can have an effect on the way that the application behaves.

In an environment that is owned and managed internally this can be bad enough. In an environment that is owned and managed by an external third party, and where project success is contingent upon successful UAT in that environment, this can be disastrous.

Best Practice: Be able to identify whether the deployment environment is as prescribed, and “fit for deployment”

One of the most common questions that arises in development projects containing more than one environment is, simply, “are these environments the same?” and its answer can be elusive.

It is essential to be able to answer that question – quickly and accurately – so that any perceived defects in the application can be categorised as “defect” or “environmental”.

This ability becomes particularly poignant where on or more of the environments are owned by different teams, or organisations.

Best Practice: Be able to prescribe what the deployment environment should look like, and have a capability to test it quickly.

The environment, as explained earlier, is a refactorable component. It can be changed, and parts can be moved or deleted. However, unlike application code, changes may need to be made to the environment in response to external events (e.g. hardware failure, or security policies).

Applications, particularly complex ones, use regression tests to ensure that observed behaviour after a change is exactly as it was before the change was made. The same should be true of the environment.

Best Practice: Automated regression tests for the environment that will compare observed behaviour both before and after changes are made.

For example, suppose that a number of operating system patches or service packs are applied to an environment where the application has been, or will be, deployed. How are these tested? Do you wait for users, or testers, to start calling to say that there are problems?

Or do you make sure that you know what problems have been introduced before your users do?

As stated earlier, the SCM repository should be used to store any artifact that can be changed and that may have an effect on the environment.

It may not seem obvious, but some of the most obscure environmental changes can cause an application to fail:

• Hostname resolution;
• Non-existent user or group accounts;
• IP and network connectivity;
• Existence, or otherwise, of files and directories ;
• Application or operating system configuration files;

It is essential that these environmental variables be placed under configuration control and able to be identified as part of a baseline.

Best Practice: Environmental artifacts that are not part of the application should be part of the baseline

Automate, Automate, Automate

Every single task that is performed as part of a development project – throughout the entire lifecycle – can be placed into one of two categories:

1. Tasks which require some form of human judgment;
2. Tasks which do not;

Tasks which fall into the first category can use some degree of automation, but should stop and wait for human intervention wherever judgment is required.

Tasks in the second category should be automated. There is no value in having expensive resources employed to do mechanical or repetitive tasks that a computer could do more quickly, accurately and consistently.

Best Practice: Automate anything that does not require human judgment

A note of caution - it may be tempting to think that automation will increase productivity on its own, but this is not necessarily the case. Automating an inefficient process will simply magnify its inefficiency – as explained in the section on Software Tools are Only Part of the Answer.

This, and it is worth repeating, is a common error – to assume that automated build software alone will improve productivity.

Best Practice: Do not automate inefficient processes, or you will only maximize the inefficiency

About BuildMonkey

BuildMonkey is a division of Nemean Technology Limited - a leading technical innovator specialising in Agile Deployment and build management.

We have over a decade of experience in helping clients increase productivity in their build, integration and test cycles. We have a track record of massively reducing costs and defects through process automation and proven methodologies.

Formed in 1999, and profitable every quarter, we invented the discipline of BuildMaster - we are the original and the best.

We provide specialist Build Management products and services - when all you do is Build Management, you get pretty good at Build Management. Our world-class Professional Services staff are the best in their field, complemented by original software products of the finest quality.

We aim to be the leading provider of Build Management products and services in the UK by providing excellent service to our customers, and by empowering Software Project Managers to aim for release on-time, on-budget, with no defects.

http://www.theserverside.com/articles/article.tss?l=TSSJS2005

Attendee Opinions