未加星标

Using Heroku with Node.js: Production-Ready Application Checklist

字体大小 | |
[前端(javascript) 所属分类 前端(javascript) | 发布者 店小二05 | 时间 2017 | 作者 红领巾 ] 0人收藏点击收藏

In this post, I'd like to teach you some of the Heroku best practices we use atRisingStack for going to production with Node.js, and give you a general checklist as well.

You are going to learn how to deploy applications to production , how to do proper logging and monitoring , and how to debug effectively.

These best practices will save you from false alarms waking you up in the nights as well as provide a consistent user experience for your users.

Step #1: Run Your Tests Automatically

All applications - not just Node.js - must have a proper test suite. The test suite functions as a safeguard, so you won't accidentally change the functionality of a given module, or worse, the whole application.

All tests in Node.js should run using the npm test command, so you should define your test commands in your package.json file's scripts section.

{ "scripts": { "test": "NODE_ENV=test mocha --require co-mocha test/setup.js '**/*.spec.js'" } }

"We recommend putting your test files next to the implementation, and name them `.spec.js`." via @RisingStack

Step #2: Do Automatic Deployments

We see lots of manual steps involved in deployment, even in bigger systems. This approach is very error-prone - in case someone forgets something, you will have a bad time. Because of this, you should never do deployment manually.

Instead of that, you can automate the whole process with great tools like Codeship or CircleCI . These tools should run your tests, and if everything is green, it should deploy your software. In CircleCI, we usually set up our tests to run these commands:

test: pre: - npm install override: - npm run lint - npm test

Once all the tests are passed, the CI has to deploy our application. But where should it deploy it to?

At RisingStack, we usually have two environments, one called Staging , and one called Production . The CI ships the application to the Staging environment. There is a manual step involved to move the application from Staging to Production. On Heroku, you have the Pipeline feature for this.


Using Heroku with Node.js: Production-Ready Application Checklist

On the UI with the Promote to production... button, you can simply push your Staging application to Production. These applications share the same codebase but can have different environment variables so that you can connect them to your staging databases.

To read more about how you should structure your applications on Heroku, I'd recommend reading the 12-factor application principles .

Step #3: Set Up Proper Logging

Logging in production is crucial. Logging in Node.js enables you to:

have a better understanding of how your applications work, discover what errors you have, find out if your services are running correctly.

Proper logging should always have a

timestamp, a format that's easily understandable for humans and machines as well, a log destination, preferably the standard output, support for log levels, so you can dynamically modify what to log.

AtRisingStack, we mostly use winston . Winston is a multi-transport async logging library for Node.js.

You can add winston to your project by installing it:

npm install winston --save

To create your first log line, you can run something like this:

const winston = require('winston') winston.log('info', 'Hello log files!', { someKey: 'some-value' })

The output of the snippet above will be:

info: Hello log files! someKey=some-value

You might notice, that the first argument to the winston.log was info - this is where you can specify the log level of a given log record. You can modify the current log level you use, with assigning the new level to winston.level , like winston.level = 'debug' . By default, winston supports error , warn , info , verbose , debug , and silly levels.

You can set the winston.level from an environment variable, like = winston.level = process.env.LOG_LEVEL , so whenever your application restarts, the new levels will be applied.

If you're looking for great log providers on Heroku, you can start using Logentries , Papertrail or Logz to store and search your logs.

Step #4: Set Up Alerts in Production

Both Logging and Monitoring is a must for production systems - as you have logging in place already, let's take on why you need monitoring and how you can set yours up!

"Getting insights into production systems is critical when you are building Node.js apps." via @RisingStack

You have an obligation to continuously detect bottlenecks and figure out what slows your product down.

An even greater issue is to handle and preempt downtimes. You must be notified as soon as they happen, preferably before your customers start to complain. Based on these needs, proper monitoring should give you at least the following features and insights into your application's behavior:

performance dashboard, to provide a quick overview of the state of your application, monitoring network connections, real-time alerting, code-level insights.

You can installTrace as Heroku addon to solve this task:


Using Heroku with Node.js: Production-Ready Application Checklist

Once you do that, you have to follow the onboarding steps - this shouldn't take more than a couple of minutes.


Using Heroku with Node.js: Production-Ready Application Checklist
Step #5: Profile your Production Systems

Profiling on the code level is essential to understand how much time does your functions take to run in the actual production environment. Luckily, Trace covers this area as well.

All you have to do is to head over to the CPU Profiles tab on the Profiling page. Here you can request and download a profile which you can load into the Chrome DevTool as well.


Using Heroku with Node.js: Production-Ready Application Checklist
Step #6: Find the Memory Leaks

Go to the Profiler page in Trace and request a new memory heap dump, then wait 5 minutes and request another. Download them and open them on Chrome DevTool’s Profiles page. Select the second one (the most recent one), and click Comparison.


Using Heroku with Node.js: Production-Ready Application Checklist
Okay, but what does this graph mean?

When you search a memory leak, you have to look for the #Delta column. Click on it, and you will see the number of additional elements in the second memory dump (compared to the first one).

On the bottom of the picture, you can see what these elements were, and you can start figuring out what caused the leak.

Heroku & Node.js = <3

Running a production app on Heroku is quite easy if you follow these best practices. Of course, there's much more to monitoring your applications performance on Heroku; we just got the basics right this time.

If you'd like to get a little bit better with measuring and optimizing your Node apps performance, I recommend to go through these articles:

Node.js Monitoring Done Right Hunting a Ghost - Finding a Memory Leak in Node.js Introducing Distributed Tracing for Microservices Monitoring

本文前端(javascript)相关术语:javascript是什么意思 javascript下载 javascript权威指南 javascript基础教程 javascript 正则表达式 javascript设计模式 javascript高级程序设计 精通javascript javascript教程

主题: Node.jsChromeCPU
分页:12
转载请注明
本文标题:Using Heroku with Node.js: Production-Ready Application Checklist
本站链接:http://www.codesec.net/view/534232.html
分享请点击:


1.凡CodeSecTeam转载的文章,均出自其它媒体或其他官网介绍,目的在于传递更多的信息,并不代表本站赞同其观点和其真实性负责;
2.转载的文章仅代表原创作者观点,与本站无关。其原创性以及文中陈述文字和内容未经本站证实,本站对该文以及其中全部或者部分内容、文字的真实性、完整性、及时性,不作出任何保证或承若;
3.如本站转载稿涉及版权等问题,请作者及时联系本站,我们会及时处理。
登录后可拥有收藏文章、关注作者等权限...
技术大类 技术大类 | 前端(javascript) | 评论(0) | 阅读(101)