Go プロジェクトのアップ時につまずいたつころ

hacker news の WebAPI を引っ張ってくるやつを作った

heroku local web コマンドにてローカルでは正常に動作していても、
PUSH で失敗することや PUSH 後にブラウザアクセス時にエラーが発生することがあった。
詰まったところを以下に記す。

Procfile

初めは以下のような形で書いていた。

1

web: ./<binary file name>

この記述だと、Heroku に PUSH 後に 「そのコマンドは実行できないよ」と怒られる。
正しくは以下のように頭にbin/をつける。

1

web: bin/<binary file name>

こちらのマニュアルにある通り、

The build process installs compiled binaries into the dyno’s ~/bin directory.
ビルドの過程においては、リポジトリのデータを dyno コンテナの ~/bin 配下にインストールするためらしい。

go.mod

依存パッケージのバージョン管理を行うための go.mod ファイルが必要。
外部ライブラリを使用していなかったので不要かと思ったが、
PUSH時に 「プロジェクトのメイン言語が何か分からないからはっきりしてくれ」と怒られるので用意しておく。
Ruby だとGemfile がないと怒られたり、Node.js だと package.json がないと怒られるみたい。

go.mod init

をとりあえず実行しておくこと。

公式のチュートリアルでは vendor/vendo.json や heroku.yml があったりして
どのファイルが不可欠なのかはっきりしない。

• vendor/vendor.json に関しては、go.modが存在すれば不要である。
• heroku.yml に関しても特にDocker を使用するのでなければ、ビルド自体に影響はない。

PORT 指定

PORT に関しては
公式ドキュメント
の通りで躓くところはないはず。
dyno 起動時に勝手にポートを当ててくれているようなので、特別こちらでポート番号を指定することもない。
(ローカルで起動するときのポート指定方法がわからなかった。heroku local PORT=5005 とやるとサーバーが立ち上がらない)

感じたこと

アプリ開発において ソースコードを書くことが最も重要と考えてはいるが、
go.modや実行ディレクトリといったサービスが稼働する環境構築についても重要だということに
改めて気づいた。
Paas を触ることに対しては（個々のサービスにロックされた使用方法を覚えるという点において）
手間に感じる部分もあったが、開発環境の構築という面において学ぶことが多いものだと気づいた。

PHP プロジェクトのアップ時につまずいたところ

PHPプロジェクトのアップにつまずいたところはありませんでした。
基本的には

• composer.json
• Procfile
  上記２つがあれば問題なさそうです。
  Procfile については

web: vendor/bin/heroku-php-apache2 /<エントリーファイルのあるディレクトリ>  

とすることで dyno 上で apache が動いてくれるようです。
Docker は試しておらず…