前面介绍了创业型软件公司的工作模式,这里详细介绍下如何实施,第一步是先要搭建环境,有了环境才能开展工作。

整个软件项目分为四个环境 开发本地环境、开发环境、测试环境、IDC环境。和传统C++开发不一样的模式是多了第一个开发本地环境。这是为什么呢,因为目前大部分开发人员还是比较熟悉windows下开发。对于mac和linux下直接使用软件并且开发的中国开发者还是少之又少,这套架构就这个现状做出来的。如下是环境搭建架构图:

agile_pic3

 

从环境来说:

一、开发本地环境、开发集成服务器搭建。 前端开发者、后台开发者。

前端开发用的最多的是photoshop和dreamweaver。在做psd之前大部分是不会协同开发的,只有整个文件传递过来过去。html切割的时候可能就会多个人协同开发了。这个时候需要一个集中ftp服务器、svn服务器。svn服务器用于保存版本代码库,用于保存历史修改的版本和开发人员协同。ftp服务器适用于及时修改时保存上传到预览服务器进行预览。看到这里有人也许会问,我直接合并svn和ftp不行吗?其实有这样的问题,如果直接提交svn,后台开发人员就会从svn看到。本来是前端的集成协同开发预览,结果影响到后台容易引起版本混乱。

后台开发怎么搭建环境?用eclipse在本地环境搭建开发环境,通过tomcat插件或者jetty启动调试class、jsp。之前看过很多公司都通过打成war包发布到集成环境再调试。集成环境大家都去集成容易引起版本混乱。即使不发布到集成环境,在本地就算修改个小的class文件也要重启war包有点浪费时间。最好就是利用tomcat的热部署,修改小功能直接生效。现在我们就是这样做的,用maven管理jar包依赖,ant本地打包、拷贝包,用eclipse的tomcat插件热部署快速开发。等到所有功能开发好了。把分支版本发布到开发环境进行集成测试。

开发环境涉及的软件有:nexus 、maven、tomcat服务器、mysql、ftp、jenkins、svn、jira、fisheye、eclipse、dreamweaver、photoshop、nginx。

软件的作用:
nexus作为集中仓库管理,因为每个工程如果都有一堆jar包,很难管理。加上svn上传、分支、合并耗费网络带宽、空间。如果有个地方把这些浪费空间的jar集中管理起来,所有工程合用岂不是很好。
maven是软件生命周期、依赖管理,有了集中管理jar包,就需要有个东西把jar包仓库和工程连接起来。
tomcat服务器是本地开发使用和集中测试服务器。
mysql就没必要每个开发机器都装一个了,放在一个开发环境就可以。
ftp作为前端开发上传文件使用。
jenkins是持续集成,开发和前端都把代码弄好,怎么融合集成在一起测试呢,总需要有个人来把所有的文件合并在一起吧?这个软件就起到这个角色,把所有文件集成、编译、打包、发布到tomcat服务器。如下图:

test

svn代码版本管理,大家都知道协同作用。
jira用于需求、bug等管理。
fisheye用于代码统计、审核等。
eclipse、dreamweaver、photoshop不用说啦。
nginx主要用于做虚拟主机和静态资源管理。因为我们可能同时开发多个网站,nginx可以根据不同的域名转发到不同的web服务器。

二、测试服务器。开发、测试。

开发集成测试环境通过后,这个就可以转测试了。通过持续集成,测试部署好环境就开始测试。测试环境同样依赖于集中仓库、maven、持续集成等软件。也就是集成测试环境、开发集成环境、开发本地环境都是用的一套jar包,是不是很cool。如果测试不通过,就要转回开发,开发好再转测试。怎么保证开发的质量和测试的质量,还有大家的协作性,这个过程涉及到软件工程和绩效考核,后面再说。测试通过一些测试,测试通过后就可以发布到外网了。这个时候需要提供发布列表、操作步骤、数据库操作脚本给到运维审核,审核通过后才能发布。

怎么发布到外网IDC呢?运维可以根据发布列表去操作,开发和前端一起等着熬夜啊熬夜。没有效率!这里提出了一个增量发布版本的方式,通过发布列表,我们的发布程序会自动检测到发布的文件和发布的机器,发布到对应的服务器。如果发布失败了还可以回滚文件,基本上是一键操作。未来还会把服务器重启、日志输出等集成起来。

三、IDC服务器。

外网的真实服务器,后台和前台。大家能够访问到的网站服务器。业务人员在版本发布后查看。整个流程就做好了。大家在每一次版本开发完了,可以很好的协同、开发、测试、发布。

扩展话题:
1、photoshop能否和html互转并且有版本管理功能,这个做好是个革命性的标志。
2、css、js等静态文件是否也能够纳入自动依赖管理里。这样不用我们发布一个页面文件时发现还有些依赖的js没有发布。

原创文章,转载请注明: 转载自LANCEYAN.COM

本文链接地址: JAVA敏捷开发环境搭建

不管是什么程序开发都可能会出现各种各样的异常。可能是程序错误,也可能是业务逻辑错误。针对这个各个开发人员都有自己的处理方式,不同的风格增加了业务系统的复杂度和维护难度。所以定义好一个统一的异常处理框架还是需要的。我们开发框架采用java实现,java中的异常一般分为两种,检查异常和运行时异常。检查异常(checked exception)有可能是程序的业务异常,这种异常一般都是开发人员自定义的、知道什么时候会抛出什么异常并进行捕捉处理。也可以是系统的异常,不捕捉编译不会通过,如  IOException、SQLException、ClassNotFoundException , 这种是必须要捕捉的并且大多都是继承Exception。 运行时异常一般都是系统抛出来的异常,这种异常不捕捉处理也不会报编译错误,如NullPointerException,ClassCastException。运行异常都是继承至RuntimeException。不管是检查异常还是运行时异常都是继承至Exception。另外还有一种异常是系统错误Error,这种异常是系统出现了故障抛出来的不能捕捉,如OutOfMemoryError。Exception和Error都是继承至Throwable。

了解了java的异常体系后,我们设计一下web框架的异常处理格式。在以往EJB时代的J2ee系统,一般是标准的三层架构:web层、业务逻辑层、数据访问层,并且每一层都分别部署在不同的机器集群中。这样我们的异常一般分为三个,WebException、BizException、DAOException分别映射到web层、业务逻辑层、数据访问层。并且这些异常都要设计的串行化可以跨机器传递生成异常链。这样的好处是看到异常链知道从哪儿抛出来的错误,比较清晰明了。

老异常链

随着后面spring的推出,java的开发越来越轻量级很多时候一台服务器可以同时部署三层并集群化,架构模式也慢慢由充血模式演变为贫血模式,再也没有了厚重的实体Bean和有状态会话Bean。针对现在轻量级的框架,异常结构如何设计呢?

先看看我们这个异常结构需要解决的问题是什么?

  1. 规范大家的异常处理方式。
  2. 简化异常处理。
  3. 区分业务异常和系统异常,业务异常需要业务逻辑支持,系统异常需要记录log。
  4. 友好的异常展示。
  5. 异常结构可扩展。

针对这些点,我的想法是开发可以使用三个类:SDKException、BizException、BizSystemException。SDKException是处理的基础类,可以在里面封装一些异常处理的基本函数。BizException是业务逻辑处理异常,一般这类异常是不需要记录log,只是展示给页面显示并提示给用户。如你的用户名、密码为空等错误。BizSystemException是业务系统异常,这类异常一般需要捕捉并记录log,比如数据库的主键冲突、sql语句错误等。按照三层架构的话,我们不可能对每一层都捕捉并且记录log,会造成重复log。可以从DAO层把捕捉到的数据库异常转换为BizSystemException抛出,如果有BizException也抛出。业务逻辑层对于BizSystemException、BizException不处理直接抛出。所有处理都在web层进行集中处理,如果是BizException,根据错误码和错误消息显示给用户对应的页面和错误消息。如果是BizSystemException告知用户系统错误,并把错误结果记入log。如果是其他异常和BizSystemException一致。这样就减少了异常处理的复杂度,开发也不用关心什么检查异常,运行时异常。

新错误结构

如果是ajax请求在做web层时,把返回的jsp变成json格式或者流格式输出即可,不影响异常框架。如采用struts2结构的代码:

public String testAjax()
{
    try
    {
         genAjaxDataStr(0, "{}");
    } catch (BizException e)
    {
         getRequest().setAttribute(this.ERRORMESSAGE, e.getErrorMessage());
         return this.ERRORJSON;
    } catch (BizSystemException e)
    {
         getRequest().setAttribute(this.ERRORMESSAGE, this.SYSTEMERROR);
         return this.ERRORJSON;
    } catch (Exception e)
    {
         this.errorTrace("test", e.getMessage(), e);
         getRequest().setAttribute(this.ERRORMESSAGE, this.SYSTEMERROR);
         return this.ERRORJSON;
    }
    return this.NONE;
}

这样前台就能根据我们的异常显示对应的错误页面了,并能把系统知道的和未知的异常记入log。

针对struts2还有个问题,在开发模式时,struts2和webwork的异常打印在页面,我们可以根据页面输出进行调试。一但部署在生产环境,需要将这个模式关闭,log就没有了。

<constant name="struts.devMode" value="false" />

为了记录一些未知的错误,需要做以下步骤:

  1. 将全局的异常映射页面从struts2的包定义里去掉。如果不去掉,在webwork不会抛出异常也就找不到出了什么问题。
  2. 扩展struts的DispatcherFilter捕捉未知的异常并记录入log。
<global-exception-mappings>
    <exception-mapping exception="com.linktong.sdk.biz.exception.BizException"
                result="checkedException" />
</global-exception-mappings>

这样,基本的异常框架就搭建完成。更进一步需要做的是:

  1. 分布式全局错误码体系,保证所有机器都共用一套错误码。
  2. 分布式部署,异常传递。可以采用hessian序列化错误码的机制,不用传输整个异常链节省带宽。
  3. 集中logger服务处理,所有机器的log统一发送到集中服务器处理。logger框架和log4j也有服务器的机制。

针对web框架、分布式部署、log服务器再讨论:)

原创文章,转载请注明: 转载自LANCEYAN.COM

本文链接地址: WEB框架的错误体系