読者です 読者をやめる 読者になる 読者になる

WonderPlanet DEVELOPER BLOG

ワンダープラネットの開発者ブログです。モバイルゲーム開発情報を発信。

「ハッカソン」を走り抜け!!

こんにちは、今回のブログ担当の近藤(英)です。

 

さて日々の開発を行っていくにあたって、日頃から新しい技術を学び、取り入れていくことを習慣化されている方も多いかと思います。

その一つの方法・場としても、「ハッカソン」という言葉が、以前より増して聞かれるようになってきたかと思います。

最近では、テレビや各メディアでのニュース、更にはエンターテイメントの一つとして番組として企画・放映されるまでになりました。

中には既に参加されて、その魅力に気づき、または虜になられた方もいるのでは無いでしょうか?(実際、私の仲間の中では年間で数十回参加される方もいる程です)

様々なジャンル、形式のものが各地で開催されるようになり、中には豪華な賞品が出るものもあり、良い腕試しの場となるものも多いと思います。

その目的も、新しい技術やサービスの創造各地域の活性化、また近年では、採用活動の一環であったり、入試の新たな方法として取り入れられたりと、多岐に渡ります。

 

「ハッカソン」は多くの場合、「アイデアソン」と対で(最近では参加する敷居を下げる意味でも、アイデアソン単独も多くなってきているようです)行われると思います、それは自然な流れで、

 

▼アイデアソン

 ・アイデア」と「マラソン」組み合わせた造語、特定のテーマについて、様々な分野の人々が集まって、ディスカッションしながら、新たなアイデアを生み出す。

▼ハッカソン

 ・「ハック」と「マラソン」を組み合わせた造語、様々な技術者達が主にチームで競い合う開発イベント。有名なものに、あの「いいね!」ボタンも、ハッカソンを通じて生まれた機能だという話もあります。

 

ですので、アイデアを捻り出し、それを形にするまでが一つの流れになります。

 

では実際には、どんなことをするのか、何が魅力で、何が大変なことなのか、この辺りについて、大会に参加した経験を元に概要と感想を時々挟みながら、おおまかにまとめていきたいと思います。

 

▼明確な期間がある

 主に24時間で企画出しから一つのサービスを創作し、最終的には審査員や聴衆にプレゼンするという超短時間勝負

 →本当に徹夜作業になることが多く、大会などの場合、当然プレゼンの場で不具合なく動くのが最低条件となるので、気を抜けないです。どれだけ良いアイデアでも、凄い技術を使用してようとも、プレゼンの約10分間が全てで、伝えられなければ意味がありません。

 

いつも担当している役割以外の作業を経験できる(しなければならない)

 少人数(最大5人程度)のメンバーで全ての作業をこなす為、例えばプレゼンに向けての資料を作成したり、デザインしたりと普段はメインとしていない作業を行うことになります。

 →私達は3人チームで参加した為、プログラムからデザイン、企画書作成まで(ディレクションなども)を全てエンジニア3人で行わなければならなかった為、非常に苦労しました。やはりチーム編成はとても大事です。

 

大会などの場合、即時に様々なジャンルのスペシャリストの方から審査を経て、様々な視点から優しく厳しい評価・助言を頂ける

 当然、大会の場合、その規模により、様々な企業がスポンサー、または審査員をされていることが多く、各メディアからの視線であったり、提供技術のスペシャリストからの指摘や助言であったりと、とても今後の為になる批評を頂けます。

 →このプレゼンでの質問などのやり取りが評価をかなり左右する気がします。時間配分が重要になり、しっかりと質問時間を設けられる方が評価に繋がると思います。

 

他チームとの交流(実装時間中や大会後の交流会など)により、技術などの情報共有や、輪を広めることができる。

 これはそのままで、まさに醍醐味とも言えると思います。他参加チームはライバルでもありますが、その前に同じ業界の技術者仲間です、どんな技術を使用するのか、時にはアイデアの助け合いなどもしたりしながら開発を進めていきます。

 →こういったコミュニケーションを経ながら、24時間の間ずっと一緒に開発を行う訳ですから、その結果如何に問わず、学生から業界の先輩まで、まさに戦友となり、この荒波の業界を生き抜いていく仲間となります。

これは普段では得難いものです。

 

実績に繫がり、乗り越えた自信につながる

 これは正直、私にとってはおまけな感じですが、賞を頂ければ実績にもなりますし、この短期間で到達できたという達成感はやっていけるという自信になります。

 →特に学生の方などについては、実際の企業での開発の超濃縮版とも言えますし、今後にとってとても有益なものになると思います。

 

・アイデアの出し方が身につく

 大会によっては、そのテーマが当日発表される事が少なくありません、アイデアは最重要と言えるものではありますが、短時間で企画をし、実装に取り掛からないと当然間に合わないので、アイデアの出し方、またはまとめ方のコツみたいなものが身につくようにります。

 →アイデアはメンバー同士がディスカッションをしながら行う訳ですが、それらの意見のまとめ方など、論理立てた方法が身につくかと思います。

 

・プレゼン力が身につく

 これもそのままで、最後には開発したものを実際に聴衆の前で披露し、その素晴らしさを伝えなければなりません、これは慣れや経験も必要となると思いますが、それを積み重ねる良い経験となると思います。

 →何せ、様々な歴戦の専門分野の方、中にはプレゼンで勝つための要員も居ますし、これだけの数のプレゼンを見れるだけでもかなりの経験となると思いますし、素直に楽しい但し自分達の分が終わった後に限る)です。

 

・でもホントにツラい、そして2度と参加しないと強く思う

 ただ単純に、精神的に体力的に追い込まれ、何を土日を費やしてやっているんだろうと思う時間帯が存在します。

 

・だがしかし、結局、全て終わった後は、また参加しようと思う

 ホントにツラいこともありますが、終わってみれば、面白いこともやはり多くて、それが勝り、また参加してみようと思い直します。

 

 これは個人的なことですが、賞を頂けると心から嬉しく、大会に負けるとホントに悔しい、何がいけなかったのかと、深く反省をし、次回までには戦える武器を増やすために、また様々な技術を身につけようと、次へ進む新たなモチベーションが生まれます。

 

と、長くなり私的な意見も多々入ってしまいましたが、「ハッカソン」は開発していくにあたって、短期間で、特に総合力を上げるのに適しているように感じます、色々な作業をする中で、自分に適しているものが新たに見つかるかもしれません、ですので、あの作業を経験してみたいが機会がない、などの場合、思いきって参加してみるのも良いきっかけかもしれません。

たとえ失敗しても、チャレンジしたことは次に繋がると思いますし、チーム戦の中では、必ず仲間からの助けがあり、自分が助けとなれることがきっとあります、これは今後の開発の中で、とても重要なことであると思います。

皆さんも是非、勇気がいることでもあると思いますが、迷っているなら参加してみると世界が変わるかもしれません、大げさではなく、実際にそうなった仲間を何人も知っています。

最終的には自分達で開催しちゃうのもありかもしれません。

 

それでは、ゴールに向かって、是非一緒にハッカソンを走り抜きましょう!!

 

 

QAのお仕事紹介

QA

クラッシュフィーバーQA(Quality Assurance)チームの櫻井です。
今回のデベロッパーブロクでは、QAの業務内容について紹介したいと思います。

とはいえ、QAってデバッグしてるだけなんじゃ?
そんな認識なのではないかと思います。
ざっくり言うと合ってますが、具体的にはこんな事してますという紹介です。


日々の作業内容

メイン:デバッグ
メインの作業は勿論デバッグです。
追加される新機能や不具合の修正に対して、

  • 挙動に問題がないか
  • 既存の動作に影響が無いか

色んな種類の端末を使って確認します。

基本的に機能を作ってくれたエンジニアさんが、
作ったコードについて、正しく動いているかを見てくれていますが、
思わぬ条件が複雑に絡み合った場合など、
作り手が予測していない条件で発生するような、そんな困ったバグを探しています。
そして見つかったら報告し、コードを修正してもらい、再度デバッグです。


2番目:テスト仕様書の作成
新しい機能が追加される時や、既存の細かな機能修正やバグ修正の時など、
ユーザー様に届けられるバージョン毎に複数の変更が入ります。
その変更をエンジニアさんが作り込んでる間に、QAチームではテスト仕様書の作成をしています。
そして作り上がった機能に対して、テスト仕様書を基にデバッグをしていく流れです。


3番目:データの整合確認
大きな流れとしては、
上記テスト仕様書の作成と、デバッグを繰り返している感じですが、
実はこれだけではなく、別軸のお仕事もあります。

クラッシュフィーバーでは、
毎週のように新ユニットの追加や新クエストの追加、復刻クエストやキャンペーンがあったり、
それに伴ったお知らせなど、色々なデータが作成されています。
ということで、そのデータの正しさの確認も実施しています。

メインで実施している新機能のデバッグもしないといけないため、お手伝いに入っている状態ですが、
こちらはチェックするデータが半端ない量であり、凄く大変です。
効率的かつ精度の高いチェックを実施しないといけません。


4番目:なんか色々

なんか色々1:サポートのサポート
デバッグをする上で仕様の把握が必須ですので、仕様に詳しくなります。
結果、CS(カスタマーサポート)のサポートも日々のお仕事です。
挙動に対する問い合わせに対して、

  • 仕様通りであるのか
  • 不具合であるのか

そのあたりの回答もしています。
ものによってはプランナーさんやエンジニアさんへ問い合わせをします。

なんか色々2:挙動の遅い端末の調査
最近クラッシュフィーバーに追加された機能で、
処理が極端に遅い端末がマルチプレイのメンバーに居ると、
エフェクトの再生に時間がかかり、あたかも進行不能に見えてしまうということが起きてしまいます。
そこで、仕方無く、処理が極端に遅い端末を使用している場合、
マルチプレイに限り、自動で演出を減らす対応が入っています。

集計されたログから、処理のスコアが規定値を下回っていた場合に、
演出を減らす対象になりますが、本当に遅い端末であるのか、
実際の端末スペックを確認する作業をしています。
デバッグで様々な端末に触れていることもあり、QAチームでやるのが効率良さそうだと思います。


まとめ

QAチームの仕事はこんな感じの作業になります。

f:id:Mikitea:20170217013339p:plain

 

現状・今後、QAとしてあるといいなと思うスキル
結構色々な作業をしている中で、
こんなスキルや経験があるといいなと思うものを挙げてみます。

▼デバッグ経験
 どのような所にバグが潜んでいるのか、経験から探す為にはあるといいですね。

コードが読める
 テスト仕様書を作成する際も、実際にデバッグする際にも、
 コード上の修正内容を知っていると、影響範囲の特定がしやすくなります。
 また、不要なデバッグを削る判断をする際にも役立ちます。

 C言語できれば大抵行ける!(はず)

SQLがかける
 データの確認や、絞り込みなど、使えると効率がグンっと上がります。

▼エクセル(スプレッドシート)が普通以上に扱える
 データまとめや関連性の分析や資料まとめなど、様々なシーンで必要になります。
 マウス無しで全てキーボードでサクサクやれると色々楽です♪ 

コミュニケーション力がある
 仕様を確認するために、他のチームへ質問しに行くことが多々あります。
 コミュニケーション力があるとその辺も円滑になります。

 

自分の職歴 

因みに自分は前職で車関係のSEを約8年間していました。
要求分析からシステムテストまで、
上流の工程から一通り経験したことや、
そこでの品質保障に関する考え方が凄く役立っています。

 

最後に、お仲間募集してます!

この記事を見て、一緒にQAをしてみたいと思えた方、
是非一緒に働きましょう!

あとこのようなQAのメンバーと一緒に
作り上げてくれるエンジニアさんやプランナーさん、
デザイナーさんも是非ワンダープラネットへ!

UnityのAnimationClip周りの小ネタ

Unity

3Dデザイナーの宮澤です。

今回はMaya等の3Dソフトから書き出したモーションデータを、

Unityに組み込む際のちょっとした小ネタを紹介します。

 

▼AnimationClipだけ取り出したい

データ削減に伴って、不要なスケルトンデータやメッシュデータは削除して、

必要なAnimationClipだけ残したい時の方法を紹介します。

①FBX内のAnimationClipを選択

②Command(Ctrl) + D 

以上で取り出すことができ、編集可能となります。

この時、複数のAnimationClipを同時に取り出すことも可能です。

f:id:wp_miyazawa:20170217103535p:plain

▼AnimationClipのリネームが面倒くさい…

FBXのファイル名を変えていてもAnimationClipの名前は決まって「Take 001」になっていると思います。

しかもFBX内にある状態だと編集不可…

f:id:wp_miyazawa:20170217103710p:plain

▼FBXデータの先頭に「@(アットマーク)」を付ける

Unityに組み込む前に、FBXのファイル名に「@」を付けるだけで、

AnimationClipの名前がファイル名と同じものに変換されます。

(AnimationClipのほうに「@」はつかない!)

f:id:wp_miyazawa:20170217103733p:plain

 

▼まとめ

・Command(Ctrl) + D でFBXからAnimationClipを取り出せる

・「@」を付けるとAnimationClipのデフォルトの名前(Take 001)がFBXと同じになる

リネームによる人的ミスでキャラクターが動かない…

なんて不幸を少しでも削減できたらと思います。

 

 

Unityプロジェクトのビルド環境改善

Jenkins Unity Xcode

アプリエンジニアの山下です。 プロダクト自体の改善はもちろんですが、開発環境を改善していくこともエンジニアの重要な仕事だと思います。

今回はUnityプロジェクトをビルドしストア提出用アプリ(ipa/apk)を作る上で 起こった問題とその解消方法についてまとめてみました。

ビルド作成時の問題

開発を進めていく上で、現行プロジェクトをビルドしてQAや開発に関わっているメンバーに配布することは多々あります。 しかし開発が進むにつれプロジェクトが膨らんでいき、ビルド手順の複雑化とビルド時間の増大が問題になってきました。

特に手順の複雑化は属人性を高め、ビルド職人がいないとビルドを作れない事態にまで及びました。 一時期ビルド手順書が作られましたが、日々の開発による手順の変化に対応できず、属人化を避けることはできませんでした。

Jenkins の導入

まず属人化解消のため、Jenkinsによる自動ビルド環境を構築しました。

特筆する点としては、作成されるapk/ipaの用途に応じて、デバッグモード有効・無効、サーバの向き先などを予め指定したジョブを複数用意しています。 一例を挙げると以下の通りです。

f:id:wp-yamas:20170203112251p:plain

  • Beta-Build (デバッグ機能有効・開発サーバ)
  • RC-Build (デバッグ機能無効・ステージングサーバ)
  • Release-Build (ストア提出用・本番サーバ)

これにより、最低限のパラメータを設定すれば、後はビルド実行をポチるだけという状態にまで落とし込みました。

またジョブは行程ごとに細分化されており、ジョブ間の連携はパラメータと成果物の受け渡しで行っています。 パラメータの受け渡しはParameterized Trigger Pluginを使用しています。

Parameterized Trigger Plugin
https://wiki.jenkins-ci.org/display/JENKINS/Parameterized+Trigger+Plugin

同じ工程は一つのジョブに集約できるため、メンテナンス性を向上しています。

f:id:wp-yamas:20170202122808p:plain

これで属人化は大きく解消できたと思います。

Mac Pro の導入

これまでビルドサーバには以下の構成のMac miniを使用していました。

Mac mini (Late 2014)
2.6 GHz Intel Core i5
16 GB 1600 MHz DDR3
Intel Iris 1536 MB
1TB HDD

そしてビルドに要していた時間がこちらです。 おおよそ1時間かかっていました。

Mac mini
    iOS … 61分41秒
    Android … 52分01秒

そのため期限が迫っているときのビルドはちょっとしたバグやオペレーションミスが命取りでした。 ビルド時間は細かい改善箇所はあれど、マシンスペックによる要因がとにかく大きいと判断したため、ここは一旦スペックの高いMac Proの導入で改善しました。

Mac Pro (Late 2013)
2.7 GHz 12-Core Intel Xeon E5
64 GB 1866 MHz DDR3
AMD FirePro D500 3072 MB
1TB SSD

6コアモデルのMac ProからCPU、RAM、SSDをそれぞれアップグレードしています。 そして実際に同じビルドを走らせた結果がこちらです。

Mac Pro
    iOS … 61分41秒 → 13分55秒
    Android … 52分01秒 → 10分52秒

ビルド時間が大きく短縮されました。

特にiOSのXcodeビルドは、IDEBuildOperationMaxNumberOfConcurrentCompileTasksオプションの指定をすることにより、並列処理する数を上げており、12コアCPUのパフォーマンスをより発揮できるようになります。

xcodebuild archive \
       CODE_SIGN_IDENTITY="${CODE_SIGN_IDENTITY}" \
       PROVISIONING_PROFILE="${PROVISIONING_PROFILE}" \
       -scheme Unity-iPhone \
       -archivePath Project.xcarchive \
       -IDEBuildOperationMaxNumberOfConcurrentCompileTasks=12

まとめ

今回はJenkinsとMac Proの導入によりビルド環境の改善を行いましたが、開発環境の問題は他にもまだまだ存在しています。 日々の改善でよりよい開発環境を実現したいと思います。

クラッシュフィーバー クライアント開発チームのご紹介

開発

おつかれさまです。エンジニアの藤澤です。 自分はクラッシュフィーバーのクライアント開発を担当しているんですが、最近ふと、いまの開発チーム(開発スタイル?)が自分にあっているというか、いまの環境 恵まれてるなあ、と感じることがありまして、今回はそれをご紹介したいと思います。

チームメンバー

現在チームのメンバーは 4 人です。

おもにバトル部分を担当する人、マルチ部分を担当する人、それ以外の部分を担当する人、といった具合におおまかに担当が分かれています。 日本人は属人化を嫌う人が多いように感じますが、担当がおおまかに分かれていることで、タスクの割り振りなどイチイチ決めなくても各々が自発的に動けますし、コードもクリーンな状態に保ててよいです。(自分の担当分以外でもだいたいの機能とかは分かっているので、その人じゃないと どうしようもない、ということもないですし)

いわゆるマネージャーはおりませんが、役割分担ができていますし、各々自分で判断して動けるメンバーが揃っているので、スムーズに動けています。

タスク管理・スケジュール管理

タスクは GitHub の Issue で管理しています。

新機能や改善要望、不具合情報など、ふだんから誰でも Issue に登録しておき、次のバージョンでどのタスクを入れるかをその中から決めます。

スケジュールは

  1. どのタスクを入れたいかと優先度、リリース予定日をプロデューサー、ディレクターが決める
  2. エンジニアがそれを見て期日内に収まりそうにないタスクを省く

といった具合に決まります。細かい工数見積もりなどはせずに さくっと決めてしまいます。

GitHub の Milestone の機能でバージョンごとに Issue をグループ化し、すべての Issue が片付いたら完了です。

スケジュール表なども作っておらず、細かいスケジュール管理もしていませんが、ひとつのバージョンの実装期間が だいたい 1 〜 2 週間なので、毎朝の進捗共有だけでこと足りています。

開発スタイル

アジャイルでやろうとか ○○型でやろうとかは とくに意識していません。

開発の流れは

  1. プロデューサーやディレクターがおおまかにやりたいことを決める
  2. プランナーが仕様をつめる
  3. 実装
  4. QA
  5. 社内リリース(新しいバージョンを実際に本番につないで しばらくプレイしてみる)
  6. 本番リリース

という感じで行ないますが、エンジニアが細かい仕様を自分で判断して先に実装を進めちゃうこともありますし、QA 期間中に実際に動かしながら「やっぱりこうしたほうがいいんじゃない」ということで軌道変更したりします。

その他

コーディングルールなどはありません。(宗教の押し付けに感じられるので……) 変数の命名はキャメル形式にしようとか、既存のコードになるべくあわせようとか、その程度です。

Git の運用は git flow と github flow の中間みたいになるのでしょうか(あまり詳しくないのですが)。

  1. master ブランチは市場に出ている最新の状態
  2. develop ブランチは開発中の最新の状態
  3. develop から feature を切って実装を行ない、develop に Pull request
  4. 複数バージョンの開発が並走する場合は develop_2.0 みたいに develop ブランチが複数存在することもある。前のバージョンがリリースされたら develop にマージし、develop を最新の状態に保つ。

という感じです。master は本番環境向けの設定、develop は開発環境向けの設定にカスタマイズしてあり、リリース時の設定変更もれとかがないようにしています。

職場環境はオープンオフィスなので、まわりの会話から他のチームの状況とか分かってよいのですが、割り込みも多くて実装に集中できないのがジレンマです……。

まとめ

これだけ書くと なんだか まともな管理もしていない無秩序な集団のようにも見えますが、決してそういうわけではなく、まだ社員ぜんぶで十数人だったころの よいベンチャーらしさみたいな部分をうまく残せているんじゃないかと思っています。

SpriteStudioのデータ容量を削減する

SpriteStudio

2Dデザイナーの木村です。
アニメーションを作っていると、ついついキーを多く打ちすぎてしまい重くなってしまった!なんてことはございませんでしょうか。
今回のデザイナー記事は、SpriteStudioのテクスチャアニメーションのデータ削減方法についてお話します。

▼ テクスチャサイズを小さくする

テスクチャのサイズを削減するには、エフェクト系の素材の大きさを1/2程度にすることがお勧めです。

エフェクトであれば、多少ぼやけていても気にならないことが多いです。一瞬しか出ないものや、αブレンド方法を加算にする素材はサイズを小さくしても問題ありません。

逆に、素材の大きさを小さくすると見栄えが悪くなるものが、テキストとくっきりした素材です。テキストの対処方法としては、1文字ずつ分けて並べるのも手です。

 

f:id:wp_harumura:20170118205730p:plain

アニメーションのデータを小さくする

1.インスタンス機能を使う

インスタンス機能とは、作ったアニメーションを「インスタンスパーツ」として別のアニメーションに配置し、再生する機能です。

複数のssaeで同じ動きを入れたい場合、1つアニメーションを作って各ssae内にインスタンスパーツを配置するだけでOKです!

この機能を使うことにより、データを小さくするだけでなく項数も削減できます。

(Photoshopでいうところのスマートオブジェクトといった感じでしょうか…)

詳しくは、こちらの公式サイトをご覧ください。

インスタンス機能の使い方 | OPTPiX Help Center

 

2.無変化キーの削除を行う

SpriteStudioには、パーツのアニメーションの演出に影響が無いアトリビュートを削除する機能があります。

アニメーションを作っていると、知らず知らずの内に余計なキーが打たれていることがありますが、この機能はキーとキーの間で何も変化していない箇所を自動で削除してくれます。

アニメーションが完成後、必ずこの機能を使いましょう!

もれなくプログラマーもデザイナーも幸せになれますヽ(*´▽´*)ノ

無変化キーの機能の場所は、こちらご覧ください。

「無変化キーの削除」ウィンドウ | OPTPiX Help Center

 

まとめ

どんなに良いアニメーションが出来ても、ゲームのローディングが遅くなるほど容量が大きくては、本末転倒です。

以前、まさにこの壁にぶち当たり四苦八苦しました。

出来上がったアニメーションのテクスチャを、後で半分のサイズにしたりなんてことが起こると、のちに全てのキーでスケールを直すといった地獄が待っています。

上記3点を行うだけでも、かなりのデータ容量削減ができますので、もしお困りでしたら是非試してみてください。

GitHubとCircleCIの連携について

GitHub CI

サーバーエンジニアの若原です。

今回は開発でも使っているCircleCIのGitHub連携について紹介させていただきます。 CircleCIとは継続的インテグレーションのためのクラウドサービスです。 GitHubと連携することができ、git pushなどをトリガーにビルドを走らせることができます。

1コンテナまでは無料で使用することが可能ですが、複数のビルドを並列で行うためにはコンテナを増やす必要があり、2つ以上のコンテナを使用したい場合は有料となります。プロジェクトの規模を考えて適切な量のコンテナ数を追加する必要があります。

サインアップ

CircleCIへはGitHubのアカウントでサインアップすることができます。

f:id:wp-wakahara:20170110020126p:plain

プロジェクトの追加

サインアップ直後にダッシュボードに遷移します。プロジェクトが存在しないため赤枠内の「Add Projects」からGitHubのプロジェクトを追加します。

f:id:wp-wakahara:20170110020026p:plain

追加したいプロジェクトの「Build project」からプロジェクトを追加します。

f:id:wp-wakahara:20170110020120p:plain

CI設定

CIの実行内容を記載する「circle.yml」を、追加したプロジェクトのrootディレクトリに設置します。

circle.ymlの以下サンプルは以下のとおりです。

machine:
  timezone: # タイムゾーン
    Asia/Tokyo
  python:   # 言語のバージョン指定(ruby,phpなど)
    version: 3.4.2
  environment: # 環境変数
    TEST_ENV: test

dependencies:
  override:
    - 依存ライブラリのインストールコマンドなど

database:
  override:
    - DBやテーブルを作成したり、サンプルデータを作成するコマンドなど

test:
  override:
    - テストを実行するコマンド
    
deployment:
  deploy:
    branch: master
    commands:
      - デプロイを実行するコマンド

他にも様々なカスタマイズが可能です。詳しくは公式サンプル をご確認ください。

作成したcircle.ymlをリポジトリにpushすることで自動的にビルドが走ります。

また、CIが不要なドキュメントのみ修正などをpushする際には、コミットコメントに[ci skip]と含めることでCIをスキップすることができます。