こんにちは！ 開発部 テクニカルコミュニケーションチーム（以下、TCチーム）の原嶋です。 さてさて。 みなさん、ドキュメントの文章校正（以下、校正）ってどんな風にやっていますか？ 目視チェックでバッチリだぜ！という方も もちろんいると思うのですが、チェックポイントが多いと指摘が漏れてしまいがちですよね。そして、会社の公式文書となれば、チェックポイントはあれもこれもと山のようになります。 TCチームでも長年 校正に頭をかかえていましたが、textlint と＋αのツール を使って、校正の悩みを解決しました。 今回はその経緯をお話させてください。 校正って確認する項目がたくさん TCチームでは、サイボウズ製品のユーザーサポートコンテンツ（ヘルプやリリースノートなど）を作成しているのですが、 それらのコンテンツは会社の公式文書なので、毎回の校正でチェックする項目が多々あるんです。 校正おわったー
CEL(Common Expression Language)で書いた条件にマッチしたIAM Policyを見つける / iam-policy-finder
こんにちは、モバイル基盤部の加藤です。 モバイル基盤部では開発者の開発環境や CI 環境の改善に取り組んでいます。 今回はその中でクックパッド Android アプリの CI 環境を CodeBuild へ移行した取り組みを紹介します。 クックパッド Android アプリで先行して移行を行った話となっていますが、他プロジェクトに関しては今後順次移行する予定となっています。 これまでの CI 環境 この記事では以前 Android アプリの CI 環境を紹介した Genymotion On Demandを使うようになってAndroidのCIがさらに1分短縮した話 からの差分を中心にご紹介します。 上記の記事をまだ読まれてない方はぜひご一読の上この記事を読まれることをおすすめします。 これまでの CI 環境の概要を説明すると以下のような図の構成となっていました。 既存環境の問題点 以前の記事
ヤフー株式会社は、2023年10月1日にLINEヤフー株式会社になりました。LINEヤフー株式会社の新しいブログはこちらです。LINEヤフー Tech Blog こんにちは。乗換案内のiOSアプリの開発を担当している田中 (@tattn)です。 ここ最近、アプリの品質を担保するための手段として継続的インテグレーション (CI: Continuous Integration)や、アプリのリリースコストを削減するための継続的デリバリ (CD: Continuous Delivery) が注目されています。 そこで今回は、自分が担当している乗換案内のiOSアプリで活用しているCI/CDの仕組みをご紹介したいと思います。 まずはiOSアプリの開発フロー自動化ツールのデファクトスタンダード fastlane について簡単に触れます。乗換案内もfastlaneを活用しています。 fastlane ht
https://testnight.connpass.com/event/41323/
はじめに こんにちは。モバイルアプリサービス部の平屋です。 2016/10/25 に「AKIBA.swift 第6回」を開催しました。本記事ではイベントの内容をレポートしていきます。 イベント概要 AKIBA.swiftとは クラスメソッド株式会社が主催する、プログラミング言語 Swift とその周辺技術の勉強会です。 発展を続ける Swift とその周辺技術の動向を追い、初心者/上級者/老若男女を問わず、情報交換の場として機能することを目的としています。 趣味/仕事で Swift に触れている方 Swiftを用いたiOS開発に携わっている方 これから Swift の勉強をはじめるという方 なんかSwiftが好きだという方 などなど大歓迎です！ 第6回は「fastlaneハンズオン」！ スピーカーに @kohei_tabataさん、@thirataさん をお迎えしてfastlaneを使った
頭の中を整理するために、新たにチーム開発を始める時に決めることをリストアップしてみました。すべて書き出すと大量になるので、プロセスや開発基盤を中心に書いています。 プロジェクト計画 ゴール マイルストン スコープ リリース計画 プロセス チーム構成 リスクと対策 プロセス スプリントスケジュール（例：月曜開始の1週間スプリント） 会議体の設定（例：スプリント計画、スプリントレビュー、レトロスペクティブ） 複数チームのワークフロー（例：プロダクトオーナー、UXデザイナー、開発チーム、QAチーム） 仮説検証サイクル（例：仮説設定、リリース、分析） 進捗管理方法（例：リリースバーンダウン） 品質管理方法 障害対応のワークフロー プロセス改善の仕組み（例：レトロスペクティブ結果のバックログ化） プロダクトデザイン（略） ソフトウェアアーキテクチャ（略） インフラアーキテクチャ（略） テスト計画（略
こんにちは、Apple Watch Series 2を買いましたtanakaです。心拍数、歩数、消費カロリーなどを数値化してくれると、日常がゲームのように感じられて楽しいですね。 最近のプロジェクトで、CakePHP3アプリをCircleCIでビルドする環境を構築しましたので、 アプリを作成するところからCircleCIでビルドするまでをご紹介します。 リポジトリがGitHubで公開されても良いなら、無料で試せますヨ。 目次 継続的インテグレーション(Continuous Integration)とは 前提 Step 1) CakePHP3アプリの作成 CircleCIでビルドするまでの流れ Step 2) GitHub上のリポジトリにPushする Step 3) CircleCI にアカウント登録 Step 4) プロジェクトを選択して、最初のビルドを実行 ビルドで何をやっているか St
みなさん、CIしてますか。 AndroidアプリのCI環境となるマシンには、Android SDKがインストールされていないといけません。今までみなさんは、どのように環境構築を行っていたでしょうか。 Gradle Plugin for Android v2.2.0で、CI環境構築が少しだけ簡単になりそうなので、紹介したいと思います。 一般的な方法 CI職人の諸兄ならば、CI環境へAndroid SDKをダウンロードするために、いずれかの方法を使ったことがあるのではないでしょうか。 android update sdk --no-ui --filter ... なコマンドをcron実行しておく Jenkins環境ならAndroid Emulator PluginにAndroid SDKを管理してもらう GradleにJakeWharton/sdk-manager-pluginを適用して、実行
こんにちは、エンジニアの堀江(@Horie1024)です。先日行われたAndroid Testing Bootcamp #2で「AndroidのCI環境をCircleCIからWerckerにした話」という内容で発表させて頂きました。発表に使用したスライドはこちらになります。 この投稿では、スライドでは単にリンクを貼って終わらせてしまったなど、詳細を紹介しきれなかった点についてご紹介しようと思います。 移行前に利用していたCircleCIによるCI環境について スライドでも紹介しましたが、iQONの開発では、1年半ほど前からCircleCIを導入していました。導入についての詳細は以下の投稿にまとめてあります。 tech.vasily.jp CircleCIで行っていたことは以下の通りです。 ユニットテスト BetaでのAPK配布 Google Playへのアップロード自動化 図にすると以下の
前提 @eaglesakura が務めているTopgate社は受託案件が多いので、この方針が絶対ではない。受注元によっては好き放題できるし、受注元によっては条件が厳しくなる。 また、弊社のAndroidアプリ開発は1人～数人で行われることが多い。そのため、この方針は更に大規模な開発では通用しない可能性があることも承知している。 その辺りは 以前の記事 でも書いたとおり。 ここに書いた方針はその時々の状況（公式ツールやSupport Library、流行り廃り）によって変化する。が、こういう構成になったのはその時時の理由があるわけなので、明文化することで後々「なぜこういう構成にしなければならなかったのか」ということを思い出せるようにもしておきたい。 環境整備 ソースコード管理 制限が無いのであれば、githubで管理する。githubのissueはRedmineに比べると機能的に不十分である
はじめに こんにちは。プラットフォーム開発部のいしがきです。普段はDMMサービス全体を支える会員基盤の開発をしています。 目次 概要 既存の自動テスト環境 既存の自動テスト環境の問題点 改善案 : Dockerの導入 実現方法 まとめ 概要 今回はCI(継続的インテグレーション)の開発工程において、自動テスト環境にDockerを導入してテストの実行時間を高速化した事例を紹介します。 既存の自動テスト環境 まず、既存の自動テスト環境を紹介します。構成はごくごく一般的なCIの構成で、下記の図のような構成になっています。 1.リポジトリ管理はStashを使用しています。 開発者は日々、ソースコードを自身のトピックブランチにcommit,push→pull request(レビュー・承認)→統合ブランチ(master)にmergeの流れです。テストコードはPHPのテストフレームワークである、Cod
概要 もう随分と前に TravisCI から CircleCI へ乗り換えたのですが、いかんせん、便利な CircleCI をもってしても Android のプロジェクトのビルド時間は長くなり続け、ついに 1 回のビルドに 20 分を費やすほどにまで成長してしまいました。いくつか無駄を省いたり、キャッシュをしてみたりと言った策を講じたものの、目立った改善が得られませんでした。そこで CircleCI を脱却してみることにしました。現在、CircleCI を脱却し Wercker を利用することで 1 回のビルドが 5 分ほどで終わるようになりました。この記事には、何がどのようにして短時間で済むようになったかを書き記してあります。 問題の根源 そもそも CircleCI で時間がかかっている部分はどこかというところから見ていきます。現在のプロジェクトで使用している分には、以下に上げる部分でか
静的解析というのは、自動テストを実行せず、コードを解析してソースコードの複雑さやバグの起こりやすさを検出してくれるサービス。テストがなくても即座に導入できる手軽さがあり、テストとは違う面でソースコードの品質を高めるのに役立ってくれる。 CI(Continuous Integration)の一種ではあるが、特にContinuous Inspectionと呼ばれることもある。「全自動コードレビュー」と言う方が近いだろうか。 Travis-CIで各種OSSを組み合わせて似たような処理を実行させることもできるが、設定が面倒くさいし、レポートをどうするか考える必要もある。特化型SaaSの方はこの辺をよく考えてくれている。 PHPに対応したInspection系のSaaSといえば、Scrutinizer、CodeClimate、SensioLabsInsightの3つが有名なので、簡単に機能面を比較し
Docker 社のユースケースでもあげられているように、CI/CD で Docker を使うというのは、プロダクションシステム以外で Docker の特性を活用できる良い場所だと考えています。ヌーラボではBacklog でのプルリクエストの提供以降、CI のジョブの実行のために Docker を利用しています。ここではその運用から学んだ５つの Tips を紹介したいと思います。 ヌーラボの CI 環境の全体図 これがヌーラボの CI 環境の全体図です。 CI には Jenkins を利用しており、Jenkins のジョブのトリガーとなるのは左側の Backlog や Typetalk です。実際には Jenkins Backlog Plugin や Jenkins Typetalk Plugin を利用してジョブを処理しています。これらのプラグインの詳細については本ブログ末に参照先をのせて
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? DockerのPros/Consとか今更感ある。他の仮想化技術との比較記事はよく目にするが、開発にどのようなメリット・デメリットがあるのかあまり周知されていないようなので自分なりの感想を書いておく。 Pros 同一性 複数人で開発する際に、環境の差が生まれない。 カプセル化 アプリケーション込みの環境をコンテナというカプセルに隠蔽することができる。 コンテナという単位に対するテストが可能に。 コンテナを捨てる・再生成するのが容易。 ポータビリティ（一貫性とも） 開発に使ったコンテナをCIでテストできる。 CIでテストしたコンテナをサーバ
目的 Swiftも2.0になり、使う機会が増えてきました。 複数人で書くことも増えてくると、コードフォーマットの統一を図りたくなってきます。 realm/SwiftLintを利用したら、github/swift-style-guideベースのチェックが出来そうです。 ローカルでやる場合は、Xcodeに設定しておけば保存などのタイミングでチェックしてくれるのですが、担当者によっては無視してしまう可能性があります。 また、SwiftLintも日々チェック項目が追加されているので、開発者のローカルのSwiftLintが古く、チェックしきれてない可能性もあります。 Androidのコードを自動で解析し、GitHubのpull requestにコメントするみたいにしておけば、CircleCI→GitHubのコメントをしてくれ、Slackと連携しておけば違反が可視化しやすそうです。 実現すること Ci
この記事はCircleCI Advent Calendar 2015 - Qiitaの14日目の記事です。 13日目はnofrmmさんですが、まだ記事が無いようです。 余談 本当は、CircleCIでのiOSビルドの有料化に伴って、個人アプリのビルドをTravisCIに移したという話をしようと思いましたが、今でもCircleCIでビルド出来てる（金は払ってない）っぽいので、一旦移行はやめました。 なので、社内で実際に構築した別のことをまとめました。 背景 iOSアプリを受託で作る場合、いろいろ面倒ですよね。主に証明書周りが。 弊社でよくあるパターンとしては、 iTunes connectなどはお客さんしか入れない。 証明書はもらえる。 UDIDが増えたら、お客さんに連絡→provisioningを発行してもらう。 ipaファイルを納品する。 という感じです。 そのため、証明書やprovis
はじめに 初めまして、気がつけば先月の25日で入社1年目を迎えた、 技術部 & Sake部部長 の@shinofara（篠原）です。 1月頃からGo言語（Golang） ばかり触りすぎて、PHPをたまに触ると; を忘れて怒られます。 困ったものです.... 今回は、僕も含めた2名で進めてきた、弊社初の Go言語（Golang） プロダクトについてのお話をしたいと思います。 少し長いですが、お付き合いいただければとてもうれしいです！ ※関係無いですが、gopher君可愛いです。 Go言語のロゴ、マスコットは2009年にRenée French(http://reneefrench.blogspot.jp/)さんによって作成・公表されました。 これらはCreative Commons Attribution 3.0 Unported License(http://creativecommons
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
