超级会员免费看
AngularJS 应用部署的综合考量
错误处理与日志记录
在进行错误处理时，有多种方式可供选择，你需要根据具体项目来考虑合适的方法。在某些场景下，将日志记录到终端用户的设备上或许是个不错的选择，但这也存在一定风险。如果选择这种方式，需要考虑信息可能被其他用户获取的问题，除非你采取了相应的保护措施。
隐藏未处理的模板
AngularJS 应用在开始工作前，需要下载应用脚本和 AngularJS 脚本。在文件下载过程中，终端用户可能会看到未处理的 AngularJS 插值表达式，这不仅影响美观，还可能造成混淆。为避免这种情况，可以使用
ng-cloak
指令。
ng-cloak
指令可以通过
display: none
隐藏 DOM 树的部分内容，直到 AngularJS 准备好处理整个页面。有两种使用方式：
-
隐藏特定部分
：
<h1 ng-cloak>Hello, {{name}}!</h1>
<p ng-cloak>It's great to see you again, you haven't logged in since {{lastLoggedIn}}</p>
- 隐藏整个页面 ：
<div ng-controller="HelloCtrl" ng-cloak>
<h1>Hello, {{name}}!</h1>
<p>It's great to see you again, you haven't logged in since {{lastLoggedIn}}</p>
<p>We hope you have a {{typeOfDay}} day!</p>
</div>
选择哪种方式取决于应用的结构。如果应用的首屏大多是动态内容，可以将
ng-cloak
指令放在控制器元素甚至
<body>
标签上；否则，可以逐个元素使用
ng-cloak
指令，让用户在应用脚本加载时查看页面的静态部分。
另外，也可以不使用双花括号，而是使用
ng-bind
指令：
<div ng-controller="HelloCtrl">
Hello, <span ng-bind="name"></span>!
</div>
采用这种方式，在脚本下载时间较长时，只会看到空白，而不是未处理的表达式。
代码压缩与合并
许多 AngularJS 应用由多个可能较大的文件组成，每个文件都需要用户的浏览器请求并通过网络传输。因此，需要考虑如何将文件缩小并减少网络请求次数。代码压缩和合并就是常用的方法。
代码压缩是将格式化良好、易于阅读的 JavaScript 源代码转换为更小的文件。例如：
-
未压缩代码
：
function getElementsByClassName(className) {
var results = [];
walkTheDOM(document.body, function (node) {
var array,
ncn = node.className;
if (ncn && ncn.split(' ').indexOf(className) >= 0) {
results.push(node);
}
});
return results;
}
- 压缩后代码 ：
function getElementsByClassName(e){var t=[];walkTheDOM(document.body,function(n)
{var r,i=n.className;if(i&&i.split(" ").indexOf(e)>=0){t.push(n)}});return t}
压缩后的代码文件更小，传输到用户浏览器的时间更短。可以使用 UglifyJS（https://github.com/mishoo/UglifyJS2）等工具进行代码压缩。
代码合并是将多个文件合并为一个文件，减少网络请求次数，提高性能。同样，有很多工具可以帮助完成这个任务。
使用这些技术时，要确保测试应用的压缩和合并版本。由于 AngularJS 使用依赖注入，压缩可能会出现问题，可以考虑使用
ng-annotate
（https://github.com/olov/ng-annotate）。
构建过程管理
如今，网站和应用越来越复杂，需要专门的构建工具和任务运行器。Grunt 和 Gulp 就是常用的任务运行器。
以 Grunt 为例，需要创建一个
Gruntfile.js
文件来配置和加载任务。以下是一个示例：
module.exports = function (grunt) {
// Part One
// Configure the various tasks we want to run
grunt.initConfig({
watch: {
build: {
files: 'src/**/*.*',
tasks: ['uglify', 'copy'],
options: {
livereload: true
}
}
},
uglify: {
options: {
mangle: true
},
my_target: {
files: {
'site/js/js.min.js': ['src/js/*.js']
}
}
},
copy: {
main: {
files: [
{expand: true, cwd: 'src/', src: ['**', '!**/assets-master/**', '!**/css/**',
'!**/js/**'], dest: 'site/'}
]
}
}
});
// Part Two
// Load the tasks we have just configured
grunt.loadNpmTasks('grunt-contrib-watch');
grunt.loadNpmTasks('grunt-contrib-uglify');
grunt.loadNpmTasks('grunt-contrib-copy');
// The task we want to run by default when we start Grunt
grunt.registerTask('default', ['watch']);
}
这个文件的主要功能如下：
1.
配置任务
：在第一部分配置了
watch
、
uglify
和
copy
任务。
2.
加载任务
：在第二部分加载配置好的任务。
3.
设置默认任务
：将
watch
任务设置为默认任务。
启动 Grunt 后，它会执行以下操作：
- 监控文件和目录的变化（
grunt-contrib-watch
任务）。
- 文件变化时压缩和合并源代码文件（
grunt-contrib-uglify
任务）。
- 将源代码文件和资产复制到分发文件夹（
grunt-contrib-copy
任务）。
可以在大约半天甚至更短的时间内学会使用 Grunt 或 Gulp 等任务运行器。如果手动执行大量任务，可以考虑采用任务运行器。更多关于 Grunt 的信息可以访问 http://gruntjs.com/，关于 Gulp 的信息可以访问 http://gulpjs.com/。
部署方式
部署是使软件系统可用的所有活动。不同项目和组织的部署细节可能差异很大。
过去，简单的 FTP 连接就可以将文件从本地机器传输到生产环境，对于小型网站，这种方法仍然适用。但随着项目变得越来越复杂，团队需要更好的管理方式。
FTP 是将文件从一个网络位置移动到另一个网络位置的可靠方法，但在项目变大时会出现问题。例如，多个开发者需要访问和编辑源代码，需要解决如何管理源代码、测试代码、将测试通过的代码部署到生产环境以及与其他开发者和利益相关者沟通项目状态等问题。
持续集成（Continuous Integration，简称 CI）就是解决这些问题的方法。典型的 CI 过程至少要实现以下目标：
1. 维护代码仓库
2. 自动化构建
3. 测试代码
4. 报告系统状态
5. 自动化部署
开发者通常需要使用版本控制系统来维护代码仓库，例如 GIT。GIT 可以帮助开发者识别和解决代码冲突，并确保其他开发者可以看到和访问自己的更改。
一个好的 CI 过程可以在开发者将更改推送到远程代码仓库时触发。代码成功构建后会进行测试，测试结果会报告给开发者和利益相关者。这样可以避免有问题的软件进入生产环境。
持续集成之所以被称为“持续”，是因为这个过程可以一天运行多次，并且集成了构建和部署过程的多个相关方面。虽然设置复杂的 CI 过程本身可能是一个项目，但作为开发者，通常通过版本控制系统进入这个过程。
综上所述，应用部署是一个复杂的多方面话题，但有很多工具和技术可以帮助管理。不需要使用所有技术，关键是关注能简化工作的方法，并在需要时深入学习。
以下是一个简单的流程图，展示了持续集成的基本过程：
graph LR
A[开发者提交代码] --> B[触发构建]
B --> C[代码构建]
C --> D[代码测试]
D --> E{测试是否通过}
E -- 是 --> F[报告状态]
E -- 否 --> G[返回修改]
F --> H[部署到生产环境]
此外，还可以用表格总结 CI 过程的主要目标：
| 目标 | 描述 |
| ---- | ---- |
| 维护代码仓库 | 使用版本控制系统管理源代码 |
| 自动化构建 | 自动编译和打包代码 |
| 测试代码 | 确保代码的质量和稳定性 |
| 报告系统状态 | 让开发者和利益相关者了解项目情况 |
| 自动化部署 | 将测试通过的代码部署到生产环境 |
AngularJS 应用部署的综合考量
持续集成的实际应用与优势
持续集成（CI）在实际开发中有着显著的优势。以一个多人协作的 AngularJS 项目为例，当多个开发者同时对代码进行修改时，很容易出现代码冲突。通过 CI 流程，开发者将代码提交到版本控制系统（如 GIT）后，系统会自动触发构建和测试。
假设开发者 A 和开发者 B 同时对一个服务模块进行了修改。开发者 A 提交代码后，CI 系统开始构建代码并运行测试。如果此时开发者 B 也提交了代码，并且与开发者 A 的修改产生了冲突，测试就会失败。CI 系统会及时报告冲突信息，开发者可以根据报告进行修改，避免有问题的代码进入生产环境。
在 CI 过程中，自动化测试是非常重要的一环。可以使用 Karma 等测试框架对 AngularJS 应用进行单元测试和集成测试。例如，对于一个控制器的测试：
describe('MyController', function() {
var $controller;
beforeEach(module('myApp'));
beforeEach(inject(function(_$controller_){
$controller = _$controller_;
}));
it('should set the correct message', function() {
var $scope = {};
var controller = $controller('MyController', { $scope: $scope });
expect($scope.message).toBe('Hello, AngularJS!');
});
});
这个测试用例确保了
MyController
在初始化时设置了正确的消息。通过自动化测试，可以在代码提交后快速发现问题，提高开发效率。
持续集成与部署的工作流程
下面是一个更详细的持续集成与部署（CI/CD）工作流程的 mermaid 流程图：
graph LR
A[开发者编写代码] --> B[提交到版本控制系统]
B --> C[触发 CI 流程]
C --> D[代码拉取]
D --> E[依赖安装]
E --> F[代码构建]
F --> G[单元测试]
G --> H{单元测试是否通过}
H -- 是 --> I[集成测试]
H -- 否 --> J[返回修改]
I --> K{集成测试是否通过}
K -- 是 --> L[代码打包]
K -- 否 --> J[返回修改]
L --> M[部署到测试环境]
M --> N[用户验收测试]
N --> O{用户验收测试是否通过}
O -- 是 --> P[部署到生产环境]
O -- 否 --> J[返回修改]
这个流程图展示了从开发者编写代码到最终部署到生产环境的完整过程。每个阶段都有相应的测试，确保代码的质量。
不同部署方式的对比
为了更清晰地了解不同部署方式的特点，我们可以用表格进行对比：
| 部署方式 | 优点 | 缺点 | 适用场景 |
| ---- | ---- | ---- | ---- |
| FTP | 简单易用，适合小型项目 | 缺乏版本控制，难以处理多人协作 | 小型静态网站 |
| 持续集成（CI） | 自动化程度高，能及时发现问题，适合多人协作 | 配置复杂，需要一定的技术基础 | 中大型项目 |
总结与建议
应用部署是一个复杂且多面的话题，涉及错误处理、代码优化、构建管理和部署方式等多个方面。在实际开发中，应根据项目的规模和需求选择合适的方法。
对于小型项目，可以采用简单的 FTP 部署方式，同时结合基本的错误处理和代码压缩。而对于中大型项目，建议引入持续集成和部署流程，使用 Grunt 或 Gulp 等任务运行器来自动化构建过程，使用 UglifyJS 等工具进行代码压缩。
在错误处理方面，要根据具体场景选择合适的日志记录方式，并注意保护用户设备上的日志信息。对于未处理模板的问题，可以使用
ng-cloak
或
ng-bind
指令来避免用户看到不美观的插值表达式。
总之，要不断关注新技术和工具，根据项目的发展适时调整部署策略，以提高开发效率和应用的稳定性。
扫一扫
24
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
