Design（システムにとって適切な設計か？） Functionality（作者が意図したとおりに振る舞うか？） Complexity（できるだけシンプルになっているか？） Tests（適切な自動テストが備わっているか？） Naming（変数やクラス、メソッドに明確な名前が付けられているか？） Comments（コメントは明確で分かりやすいか？） Style（コードはスタイルガイドに従っているか？） Documentation（関連するドキュメントは更新されているか？） https://google.github.io/eng-practices/review/reviewer/
Month: September 2019
记得去年此时，CI/CD还是相当的火。SRE工程师的招聘职位也很多。但是不得不感叹技术发展之迅速。到今年，CI/CD已经成了必备功能，很少再听到专门拿出来说事了。 最近在拿springboot做一个小项目，部署到ec2上面。刚好客户那边对CI/CD也有需求，于是就尝试了下codebuild，codedeploy跟codepipeline的组合。 网上关于这方面的介绍已经很多了，我只把自己尝试过程中踩过的一些坑发出来作为分享。 Codebuild 我的springboot项目是拿maven做管理的，所以其实codebuild只是帮你执行了以下mvn install的命令而已。（这里要吐槽以下codebuild不够智能的地方：local几秒钟build完成的东西，在codebuild上，每次都要重新下载所有依存的jar包，每次都要多花去5-6分钟）只是唯一要注意一点的地方，为了deploy顺利进行，需要把appspec.yml跟jar包传递给codedeploy。 version: 0.2 phases: install: runtime-versions: java: corretto8 build: commands: – mvn install artifacts: files: – target/cms-0.0.1.jar – appspec.yml –
之前为了解决github跟slack用户相关联的问题，拿hubot在heroku上面部署了一个小程序，但是偶尔会出现程序虽然在运行，但是slack通知不成功的现象。 这些往往出现在程序运行一两个小时以后，重新启动heroku的dyno可以暂时消除问题，但依旧无法解决问题。 后来猜测，是不是长时间不调用webhook，或者不使用hubot，就会导致程序挂起，于是，在heroku的addon里，安装了一个Heroku Scheduler、然后添加了以下命令，尝试10分钟health check一次。 $ curl -X ‘POST’ -H ‘X-Github-Event:health_check’ https://xxx.herokuapp.com/webhook 但是很遗憾，过一段时间后，slack依旧通知不成功。 后来就考虑能不能定时重启dyno，这样总可以了吧。 在网上找了一些hroku重启的方法，大部分都是 heroku restart 的方法。但是这是安装了heroku的cli的前提下，我们部署到的heroku服务器上，其实是没有安装cli的。后来，在stackoverflow上面，看到其实heroku有提供api，于是采用了以下方法，定时重启dyno，算是暂时解决问题了。 $ curl -n -X DELETE https://api.heroku.com/apps/xx/dynos -H “Content-Type:
