こんにちは。いつもSiderをご利用頂きありがとうございます。
SiderがMISRA C コーディングガイドラインの解析に対応いたしましたので、ご紹介します。
これにより、プルリクエスト単位で、そのプルリクエスト内で修正されたソースコードがMISRA C:2012に違反していないかを常時チェックすることが出来ます。

SiderではCppcheckという解析エンジンを用いております。そのエンジンのアドオンmisraを有効にする記載を、Siderの設定ファイルに記載していただくことでご利用いただけます。

sider.yml

linter:
  cppcheck:
    addon:
      - misra

MISRA C とは？

MISRA C とは Motor Industry Software Reliability Association (MISRA) が策定しているC言語のコーディングガイドラインです。
組み込み制御システムや車載ソフトウェアといった高い水準の安全性を求められるソフトウェアの開発者向けに、ガイドラインのベストプラクティスを提供しています。

MISRA C はもともと自動車分野向けに策定されました。しかし、今日では鉄道/航空宇宙/医療機器などの幅広い組み込みソフトウェア分野でも採用されています。
このような高い水準の安全を求められる開発現場で、安全性/可搬性/信頼性を確保するために MISRA C ガイドラインを利用する場面が増えております。

Siderの Cppcheck MISRA C アドオン対応

Siderは既にC/C++言語向けにCppcheckのサポートしておりましたが、今回、 MISRA C アドオンに対応いたしました。

Cppcheckの MISRA C アドオンでルールのメッセージを表示するためには、使用者ごとにMISRAからガイドラインのドキュメントを購入する必要があります。
しかし、このたび、SiderはMISRAと契約を締結しましたので、ルールのメッセージを当プロダクトに組み込んで提供を開始いたしました。
なお、そのルールのメッセージは無制限には公開できないため、解析対象がprivateなレポジトリの場合のみ表示されます。

もし、複数の解析器を有効にして実行していたり、報告されたissueの数が多い場合には、「高度な検索」をクリックしてフィルタしてください。ツールとして Cppcheck、そして所望のルールIDを適用することで、 MISRA C の結果のみを表示することができます。

MISRA C:2012 のSiderのカバー範囲

SiderではCppcheckの MISRA C アドオンを利用して、MISRA C:2012 の143件のルールのうち99件をサポートしています。カバーしていない44件ほどはSiderではチェックすることは出来ません。
それらの項目の多くはコンパイルが必要なためであり、迅速に解析を行うSiderのサービス性質上提供が難しいため、現時点ではそれらを提供する予定はありませんが、欠落しているそれらのルールについての一部はgccなどを使っていただくことで補っていただく事ができます。

Sider（内のCppcheck MISRAアドオン）でPull Request・Merge Request単位を高速に解析し、必要に応じて、CI/CDなどでコンパイラをあわせてご利用いただき、カバー範囲を増やしていただくのが良いかと思います。

他社のMISRA Cチェック機能を持つ製品との比較・使い分けについて

MISRA C設計標準規格をチェックする製品は非常に多く存在しています。よく知られているものだと、Synopsis社のCoverity静的解析ソリューションや、PARASOFT社のC++test、Micro Focus社のFortifyなどがあります。それらとSiderの違いについて2軸で説明させていただきます。

アジャイル開発、GitHub/GitLabを用いた開発に最適化されたSider

Siderは比較的新しい製品です。現時点では、ローカルでのコマンドライン実行やIDEとの連携、Jenkins（CI/CDサーバー）上での実行などには対応していません。一方で、GitHubやGitLabのPull Request・Merge Requestとの連携に対応しています。
他社製品であればQAフェーズの前工程やQAフェーズなど、開発工程の後半で利用することが主だった利用シーンですが、Siderの場合は最初のコミットから、差分だけを確認をして、MISRA規約違反のコードを発見、修正していくことが出来ます。そのため、他社様の製品をすでにご利用頂いている環境にSiderを導入いただいた場合、それらの製品で後工程で確認する際に、Siderが指摘した分の内容が減るため、後ろの工程での修正や対応時間などを減らすことが出来ます。

開発者は昔に書いたコードを再度確認して修正するのではなく、ついさっき書いたコードに対して、Pull Request・Merge Request単位で確認をし、迅速に修正を行うことが出来ます。それにより高い生産性でMISRA準拠のコードを書くことが出来ます。

非常に安価。1500円から利用可能。追加費用もなし

Siderは1ユーザーあたり月額1500円の利用料でご利用いただけます。クラウド版の場合、サーバーコストも掛かりませんので、非常に安価にご利用いただけます。また、インストールも数クリックと、先述の通り設定ファイルを数行書くだけで済むため、総合的に様々な面でコストは非常に低いです。

1プロジェクトあたり数百万円単位の製品が多い中、プロジェクト数は無制限、ユーザーあたり1500円（100名の場合でも月間15万円、年間180万円でプロジェクト数無制限）と非常に安価であるため、ぜひご検討を頂ければ幸いです。

Pull RequestやMerge Requestだけでなくプロジェクト全体を検査したい

MISRA C規格に準拠しているかの確認についてはおそらく、Pull RequestやMerge Request単位だけでなく、プロジェクト・リポジトリ全体を検査したいというニーズもあるかと思います。
こちらの機能は近日中に提供予定です。少々お待ち下さい。ご興味ある方がいらっしゃいましたらぜひお問い合わせください。

おわりに

Siderはユーザ様のニーズに合わせて様々な発展・機能追加や対応言語追加などを行っております。
ぜひSiderをご利用いただき、また、なにかご要望がありましたら下記製品サイトの画面右下のチャットよりお声がけください。

sider.review

今後ともSiderをどうぞよろしくお願いいたします。

The post SiderでMISRA C規格準拠チェックが可能に。組み込みソフトウェアの開発にSiderによるMISRA C/C++チェックを appeared first on Sider Labs Blog.

Version v1.01.00.017

表示変更

• ダッシュボードのレイアウトを一部修正しました。

不具合修正

• 軽微な不具合を修正しました。

The post リリースノート2020年11月24日 appeared first on Sider Labs Blog.

Version v1.01.00.021

機能追加

• Java Script/Type Script 言語に対応しました

不具合修正

• 軽微な不具合を修正しました。

The post リリースノート 2020年12月15日 appeared first on Sider Labs Blog.

株式会社スリークは、ソフトウェア開発者向け各種製品を提供してまいりましたが、このたび事業の選択と集中を結実するため、所有する全サービス名を”Sider”ブランドに統一いたしました。これにより、ソースコードレビューサービス Sider の新機能開発を加速してまいります。また、これに合わせて、サービス名と商号の認知度をより高めることを目的とし、商号を株式会社スリークから株式会社Sider へと変更いたします。

Sider ブランドへの統一の背景

近年、市場のニーズを捉えた製品をいち早くリリースするために、ソフトウェア開発サイクルはますます速くなってきています。その一方で、ソフトウェア自体に求められる機能は多様化し、開発の難易度は上がっています。高品質のソフトウェアをいかに迅速にリリースするかは、多くの企業にとって、ビジネス上の最大の課題の一つともなっています。

ソフトウェア品質と開発スピードの両立のための一つの解が、ソースコードレレビューとアジャイル開発手法です。当社は、ソースコードレビューを導入しているエンジニアチーム向けにコードレビューの自動化ソリューション”Sider” を提供して参りました。また、アジャイル開発プロセスを導入しているチーム向けのマネージメントソリューション “Sleeek” も併せて提供して参りました。

この度、Sider 自身の開発スピードを上げるため、これら製品を”Sider” ブランドで統一いたします。これにより、当社はソースコードレビュープロセスを効率化するための革新的な機能の開発に注力して参ります。旧Sleeek 製品は、”Sider Team Insights” として、チームメンバーの行動分析の観点で、ひきつづきエンジニアの開発体験の向上に貢献いたします。それぞれの製品ページは以下のとおりです。

• 自動ソースコードレビューサービス Sider
• 自動プロジェクトレビューサービス Sider Team Insights

本件に関連するプレスリリースURL

• コードレビュー自動化サービス Sider、開発者向け製品群をSider ブランドに統一し、あらゆるエンジニアの開発体験を向上させるために製品開発を加速
• 連結子会社の商号変更に関するお知らせ(当社親会社 株式会社フィックスターズによる)

The post 製品群のSider ブランドへの統一と商号変更のお知らせ appeared first on Sider Labs Blog.

Version v1.01.00.025

機能追加

• 解析結果データを削除するためのボタンを設置しました
• クローンの統計情報の表示をシンプルに変更しました
• 製品のトップページにチュートリアルビデオを設置しました

不具合修正

• 軽微な不具合を修正しました。

The post リリースノート2020年12月28日 appeared first on Sider Labs Blog.

Version v1.01.00.027

機能追加

• Swift 言語の解析に対応しました

不具合修正

• 軽微な不具合を修正しました。

Sider Labsは、開発者にとって有益な情報を提供できるよう今後も性能改善・機能拡張を続けてまいります。引き続きよろしくお願いいたします。

The post リリースノート2021年1月12日 appeared first on Sider Labs Blog.

Version v1.01.00.028

機能追加

• Java 言語の解析に対応しました
• Ruby 言語の解析に対応しました
• PHP 言語の解析に対応しました

不具合修正

• 軽微な不具合を修正しました。

Sider Labsは、開発者にとって有益な情報を提供できるよう今後も性能改善・機能拡張を続けてまいります。引き続きよろしくお願いいたします。

The post リリースノート2021年1月18日 appeared first on Sider Labs Blog.

Version v1.01.00.030

機能追加

• クローン比較画面に機能説明動画を追加しました
• クローン比較画面の統計情報表示部を変更しました

不具合修正

• 軽微な不具合を修正しました。

Sider Labsは、開発者にとって有益な情報を提供できるよう今後も性能改善・機能拡張を続けてまいります。引き続きよろしくお願いいたします。

The post リリースノート2021年2月1日 appeared first on Sider Labs Blog.

Version v1.01.00.031

機能追加

• 複数の解析結果を保持できるようになりました

今までは、一つの解析に対して一つの解析結果を保持していました。本バージョンから、複数の解析結果を保持できるようになっています。これにより例えば、先週のレポジトリを解析した結果と今週のレポジトリを解析した結果を、ダッシュボードを切り替えて閲覧できるようになりました。

データの保存先は今までと変わらずブラウザ内部のIndexed DB 内部です。つまり、ユーザーのローカルPCに保存されていて、外部サーバーなどに解析結果を送るようなことはしておりませんのでご安心下さい(参考リンク)。ただし、ブラウザ内のデータ容量の制限から、現在は、保持できる解析結果の数は2つまでに制限されております。ご了承下さい。なお、この解析結果の制限は、Sider 製品版としてリリースされる際には無くなる予定です。

不具合修正

• 軽微な不具合を修正しました。

Sider Labsは、開発者にとって有益な情報を提供できるよう今後も性能改善・機能拡張を続けてまいります。引き続きよろしくお願いいたします。

The post リリースノート2021年2月8日 appeared first on Sider Labs Blog.

Siderでは様々な解析器をサポートしており、それらにはプログラミング言語ごとのカルチャーなどに応じて適切と思われる設定値を社内で検討し、デフォルト設定として提供してきました。ユーザー様が解析器の設定を独自に行わない場合、そのデフォルト設定が適用されています。

そのデフォルト設定を今後、学術機関との共同研究の成果によって生み出された、定量的にデフォルト設定として適切であると考えられるルール（以下、Recommended Rulesと記載）に置き換えていきます。

提供スケジュールは本記事で随時更新をしていきますので対象となる解析器をご利用の方は次の3点をご認識ください。

• デフォルト設定でSiderを利用中の場合出力する指摘が変わる可能性がある
• デフォルト設定置き換えに先立って試すことが出来る
• 以前の設定値もユーザ様独自の設定として設定ファイルを作成いただければ適用出来る

本記事では次の内容を記載させて頂きます。

1. Recommended Rules概要
2. 解析器ごとのRecommended Rulesの適用開始日（デフォルト置き換え）
3. 解析器ごとのRecommended Rulesのオプトイン・提供開始予定日とリンク
4. Recommended Rulesをすぐに利用されたい場合の利用方法
5. Recommended Rulesについての詳細

Recommended Rules概要

新しいコーディングガイド（解析ルール）を2020年12月22日にプレスリリースにて発表させていただいたきました。そして、この私達が推奨する解析ルールのセットを「Recommended Rules」と名付けました。
https://prtimes.jp/main/html/rd/p/000000006.000054556.html

Recommended Rulesは「どのようなプロジェクトであっても有益であるコーディングガイド」であることを目標にし作られました。これをSiderのデフォルト設定として提供させていただき、その後プロジェクトに合わせて必要なルールを追加（有効化）していくことで、プロジェクトにあったガイドの設定と運用が簡単にできるようになります。

Recommended Rulesは、GitHub上で公開されている人気のリポジトリを分析し、実際に守られている（多くのOSS開発者が守っている）ルールのみを抽出したものです。それにより、Siderがうるさくなく、かつ、有益なルール（Siderが指摘しなければ人が指摘するだろう物など）を提供するようになっています。ぜひご活用ください。

解析器ごとのRecommended Rulesの適用開始日（デフォルト設定変更）

以下に記載のある解析器については順次Recommended Rulesが適用されていきます。日付は準備が出来次第アップデートさせて頂きます。莫大な量のソースコード、ルールの遵守の度合いを解析し、それを元に策定していることから、提供タイミングにラグがあることをご了承ください。

• Ruby
  • RuboCop 2020年4月1日予定
• Java
  • Checkstyle 2021年3月16日予定
• JavaScript and Flavors
  • ESLint 2020年4月1日予定
• PHP
  • PHP_CodeSniffer 2021年3月16日予定
• Python
  • Flake8  2021年3月16日予定
• C/C++
  • cpplint 2020年12月22日

上記に記載をしなかった以下の解析器についてはスケジュールは未定となっております。提供が行われない場合もございます。

• Ruby
  • Reek
  • HAML-Lint
• Java
  • PMD
• Kotlin
  • detekt
• Swift
  • SwiftLint
• PHP
  • PHPMD
• Go
  • GolangCI-Lint
• C/C++
  • Cppcheck
• C#
  • FxCop

上記に記載のない解析器については検討中です。セキュリティに関する解析器などの全てのルールに対応する必要がある解析器、ユーザーが任意のルールを書くことが出来るSider製の解析器などについてはRecommended Rulesの役割に沿わないため提供を行う予定はありません。

解析器ごとのRecommended Rulesの提供（オプトイン）開始予定日とリンク

Recommended Rulesの設定ファイルを下記に記載のURLにて配布しています。

ダウンロードし、リポジトリに配置頂き、解析器によっては明示的にsider.ymlでそのファイルを指定頂ますようお願いいたします。その設定を行っていただくことにより、デフォルト設定として反映されるのを待たずしてRecommended Rulesを利用することが可能です。

• Ruby
  • RuboCop 2021年3月予定
• Java
  • Checkstyle
    • https://github.com/sider/runners/blob/HEAD/images/checkstyle/sider_recommended_checkstyle.xml
• JavaScript and Flavors
  • ESLint 2021年3月予定
• PHP
  • PHP_CodeSniffer 2021年2月中予定
• Python
  • Flake8 2021年2月
    • https://github.com/sider/runners/blob/HEAD/images/flake8/sider_recommended_flake8.ini
• C/C++
  • cpplint
    • https://github.com/sider/runners/blob/HEAD/images/cpplint/sider_recommended_CPPLINT.cfg

各解析器でのルールの指定の仕方は下記ヘルプサイトから該当する解析器のページにてご確認ください。
https://help.sider.review/getting-started/custom-configuration

Recommended Rulesについての詳細

Recommended Rulesは学術機関との共同研究の成果によって当社にて開発を行ったものです。
詳細については今後、論文として新たに公開をする予定です。公開しましたらこちらにリンクを記載させていただく予定です。

現時点で公開済みの参考論文、また、本研究の共同研究先は下記のとおりです。

• 参考論文・ポスター等
  • 倉重 徹, 末次 健太郎, 角 幸一郎, 名倉 正剛, 高田 眞吾, 浅原 明広: OSS を対象にしたコーディング規約違反発生状況の調査, ソフトウェアエンジニアリングシンポジウム2020 (SES2020)，ポスター セッション（2020年9月）
  • 名倉正剛, 田口健介, 高田眞吾: コーディング規約違反メトリクスに基づきソフトウェア変更に対して不具合混入を予測する手法, 情報処理学会論文誌61巻4号, pp.,895-907 (2020年4月)
• 共同研究先
  • 慶應義塾大学理工学部情報工学科高田研究室 高田眞吾教授
  • 南山大学理工学部ソフトウェア工学科 名倉正剛准教授

まとめ

Recommended RulesがSiderのデフォルト設定として今後適用されます。Siderのデフォルト設定を現在ご利用の方は指摘の量が増える・減るといった何らかの影響が発生します。予めご承知おきください。また、ご不安な方や先に試されたい方、この機会に設定をカスタマイズしていきたい方は本記事で紹介しているURLからRecommended Rulesをダウンロード頂き、リポジトリ内に配置し、ご設定ください。

今後もSiderでは新しい機能、取り組みを進めていきます。今後ともどうぞよろしくお願いいたします。

The post Siderの新しい推奨コーディングガイド「Recommended Rules」の提供・適用開始スケジュールのご案内 appeared first on Sider Labs Blog.

Version v1.01.00.035

機能追加

• フィードバック返信機能が追加されました

コードクローンを横並びで詳細表示する画面で、そのコードクローンが需要であったかどうかのフィードバックを送信する機能を追加いたしました。我々が取得するデータは

• あなたのフィードバック情報(はい/いいえ/そこそこ重要)
• クローンコードのプログラミング言語
• 類似ステートメントの数
• 類似度スコア
• クローンが同一ファイルにあるか、異なるファイルにあるか
• 同じクローングループに含まれるクローンの数

になります。皆様のソースコードを送信することはございません。 フィードバックいただいた情報は、今後の製品の性能向上に利用させて頂きます。

不具合修正

• Java のクローン検出エンジンにおいて、import 文はクローンとはみなさないように修正しました。
• その他、軽微な不具合を修正しました。

  Sider Labsは、開発者にとって有益な情報を提供できるよう今後も性能改善・機能拡張を続けてまいります。引き続きよろしくお願いいたします。

The post リリースノート2021年3月13日 appeared first on Sider Labs Blog.

Siderに新たに2つの機能を追加しました。
どちらも「ソースコードのリファクタリングをするべきファイルを見つける」ことを支援する機能です。

コードの複雑性、重複度、行数、Siderが検出した問題の数などの複数のメトリクスを提示します。それによって、リファクタリングすることによって開発生産性を上げられるであろうファイル・ソースコードを容易に見つけられるようになります。また、合わせて表示されるファイルの変更頻度から、より優先的に対処すべきものかどうかの判断も可能です。

リファクタリングする価値のあるファイルを見つける

Siderでは、解析対象として設定したGitHubリポジトリ内の全てのファイルを検査し、静的解析によりソースコードの問題を抽出する機能を昨年に提供を開始しました。今回の機能追加ではそれに加え、コードの循環的複雑度（ネストの深さ、分岐の多さなど）、重複したコードの数や量、コードの行数、各ファイルの変更頻度などを分析し、スコアを付けました。そして、それらのうち上位30ファイルをグラフにプロットしました。このように、どのファイルに変更を加えると開発生産性の向上に役立つかを可視化しました。

プロジェクト全体のコード品質、問題を確認する

プロジェクトの全てのファイルのメトリクスやそのファイルが抱えている問題を1つずつ確認できる機能も新たに提供しました。Pull Requestの変更範囲だけではなく、プロジェクト全体の問題を一括して調べることが出来ます。

さらにIssuesページでは特定の問題、例えば「セキュリティに関する問題」だけをフィルタリングして表示することも可能です。

ご利用方法

リポジトリごとにデフォルトで解析するブランチを設定していただくことでそのブランチが解析されるようになります。本機能はデフォルトでは無効に設定されていますので、リポジトリごとにどのブランチを解析対象とするかを設定してください。

もしくは、Siderのリポジトリのページにある「Branches」タブから任意のブランチを任意のタイミングで解析することもできます。

おわりに

Siderは今後も積極的な機能強化を図り、ソフトウェア開発者の生産性の向上に寄与します。世界No.1のコードレビュー自動化サービスを目指して参りますので、引き続きご利用、応援を頂ければ幸いです。

The post Siderに強力な新機能が追加。コード品質の可視化、リファクタリングすべきファイルの可視化が可能に appeared first on Sider Labs Blog.

SiderにSecret Scanという新しい機能が加わりました。Secret ScanはAPIのシークレットキー、RSA秘密鍵などの秘密情報がGitHub Pull Request内に含まれていないかを自動的に検査する機能です。Pull Requestの更新毎に自動的に検査されます。

先日提供を開始したブランチ全体を解析する機能でも検査可能なため、現在のリポジトリ・ソースコード内に秘密情報が含まれないかどうかを検査することが可能です。もしSiderから秘密情報を含むコードをコミットしてしまっていることが報告された場合、その秘密情報は速やかに無効化して下さい。

Secret Scanの動作イメージ

Secret Scanのご利用方法

Secret Scanはリポジトリ設定のToolsからSecret ScanをEnableにしていただく事でご利用いただけます。

セキュリティに関する問題を検出することは非常に重要であるため、Siderを利用されている全てのリポジトリでこの機能は有効に設定される予定です。

提供に至った背景

セキュリティに関する検査を行う商用サービスは以前から多くあります。その多くはGitと連携出来ないものでしたが、最近ではGitHubに対応したものも提供されるようになりました。

いくつかの企業がそういった製品を提供していますが、今回のSider Secret Scanが低価格かつ機能のカバー範囲が大きいことから総合的に優れていると考えております。

本機能はSiderの全てのユーザ様が追加の料金のお支払いなくご利用をいただけます。

おわりに

ソフトウェア開発におけるセキュリティへの取り組みは非常に重要です。DevSecOpsに対する取り組みへの重要度は高まっています。コーディング時にセキュリティに関する問題を未然に防ぐためにSiderで秘密鍵等のクレデンシャルがソースコードに含まれることを抑止するSecret Scan機能をリリースしました。

今後もDevSecOpsに必要な機能の提供を図っていく予定です。今後もぜひご利用下さい。

The post 秘密鍵・APIトークンなどのクレデンシャル情報のコードへの流入を防ぐ、Secret Scanの提供を開始 appeared first on Sider Labs Blog.

いつもSiderをご利用いただきありがとうございます。sider.reviewはメンテナンスのため、以下の日程でサービスを一時停止します。

2021年8月4日（水）22時-23時（日本時間）

この時間、GitHub上で作成されたプルリクエストに対する解析が行われなくなるため、GitHub上でのワークフローに影響が出る恐れがあります。 メンテナンス中に作成されたプルリクエストをメンテナンス後にSiderに解析させるには、新しいコミットをpushするか、プルリクエストをリオープンするようお願い致します。

メンテナンスの進捗は、ステータスページでご確認いただけます。

ご不便をおかけしますが、ご理解のほどよろしくお願い致します。

The post 2021年8月4日（水）メンテナンスによるサービス一時停止のお知らせ appeared first on Sider Labs Blog.

AWS CodeBuild に Sider Scan を導入する方法について記述します。

前提条件

まず、AWS のアカウントを持ち、CodeCommit でコード管理を行い、CodeBuild, CodePipeline を使用し CI/CD を使用していることが条件となります。また、Sider Scan のアーティファクトの保存読込のため、S3 のバケット作成とアクセス権限も必要となります。

また、Docker Hub から CodeBuild への image pull は制限があり、Docker Hub のアカウントも必要となります。

ビルドの詳細

まず、Sider Scan 設定ファイル .siderscan.json を、解析対象のリポジトリに置きます。フォーマットについては Docker版Sider Scan (v2) をご覧下さい。

Sider Scan は実行に大きな時間がかかり、特に成熟した大きなプロジェクトでは1時間以上実行にかかることもあります。CodeBuild のデフォルトのタイムアウトは8時間ですが、もしそれ以上かかることがあれば、タイムアウトの設定をお願いいたします。

環境について述べます。新しい環境イメージはマネージド型イメージ、オペレーティングシステムは Ubuntu、ランタイムは Standard、イメージはデフォルトのもの、環境タイプは Linux を選びます。Docker を使用するため、特権付与をお願いいたします。Docker アカウントの環境変数 DOCKERHUB_USERNAME, DOCKERHUB_PASSWORD の追加もお願いいたします。

Buildspec は次のように設定します。

version: 0.2

phases:
  install:
    commands:
       - echo $DOCKERHUB_PASSWORD | docker login -u $DOCKERHUB_USERNAME --password-stdin
       - docker image pull sider/sider_scan_runner:latest
  pre_build:
    commands:
       - aws s3 cp s3://[S3のバケット名]/[リポジトリ名]/output.radump ./
    on-failure: CONTINUE
  build:
    commands:
       - mkdir -p scan_result/${CODEBUILD_BUILD_NUMBER}
       - |
        docker run --rm -v $(pwd):/target -w /target sider/sider_scan_runner:latest sider run \
        -c /target/.siderscan.json \
        -p /target/src \
        -f /target/output.radump \
        -u https://[S3のバケットURL]/[リポジトリ名]/ \
        -o /target/scan_result/${CODEBUILD_BUILD_NUMBER} \
        -t test01@example.com
artifacts:
  files:
     - scan_result/${CODEBUILD_BUILD_NUMBER}/*
     - output.radump

アーティファクトについて述べます。タイプは S3、バケット名はアーティファクトを保存読込する場所を指定、名前はリポジトリ名を入れます。セマンティックバージョニングの有効化、パス、名前空間のタイプ、アーティファクトのパッケージ化はなし、でお願いいたします。解析結果はアーティファクトとして保存し、Webから見れるようにする必要があり、アーティファクト暗号化の削除をチェックします。

S3 バケットのディレクトリ scan_result 下を Web から見れるように設定することで、要確認コードの通知にあるリンクを開くことで、その詳細をブラウザから確認することができます。

解析の流れ

解析全体のフェーズは次のようになります。

1. Sider Scan の Docker イメージを pull します。
2. 過去のアーティファクトから、解析結果ファイル output.radump をダウンロードします。
3. Sider Scan を実行し、要確認コードを検索します。
4. 過去の解析結果ファイルと比較することで、新しく見つかった要確認コードの詳細レポートを S3 に保存します。
5. 同時にメールなどの通知を行います。通知内にはリンクがあり、それを開くことで詳細を見ることができます。
6. 解析結果ファイルを更新し、アーティファクトとして保存します。

The post AWS CodeBuild への導入方法 (v2) appeared first on Sider Labs Blog.

いつもSiderをご利用いただきまして、ありがとうございます。

この度、更なるユーザ体験の向上を目的として、Sider利用時のGitHub Organizationに要求する権限を変更します。この変更により、GitHub Checks APIに対するRead, Write権限を追加で要求します。この権限は、GitHubとSiderのようなCI/CDサービスの連携を強化するためのAPIです。

GitHubより権限の追加を確認するE-mail（※）が届きますので、内容を確認の上、承認をお願い致します。なお、権限追加の承認はOrganizationのOwnerのみが実行できますので、必要に応じてOrganizationの管理者に対応をご依頼いただければ幸いです。
※[GitHub] Sider is requesting updated permissionsという件名のメールです。

なお、権限追加が承認されない場合でも、Siderのサービスはこれまで通りご利用いただけます。しかしながら、今後新しく提供する機能のご利用に制約が出る可能性がございます。（新機能の提供時期については、決定次第改めてご連絡致します）

お手数をおかけして恐縮ですが、よろしくお願い致します。

The post Siderご利用に伴うGitHub Appsの権限追加について appeared first on Sider Labs Blog.

いまさら Lines-of-code? 

　ソースコードの規模を測定する際に、最もよく使われるメトリクスはコード行数、いわゆるLines-of-code (LOC) でしょう。古くからあるメトリクスである上に、計測も簡単にできます。Linux 環境であれば、wc -l コマンド一発ですし、エディタで常時表示させることもできます。

　ただし、ご存知とおりLOC は取り扱いが難しいメトリクスでもあります。特に、LOC を作業量の見積もりや、開発チームのパフォーマンスの計測に使う場合は、使い方を誤ると批判が生まれます。例えば、2つの異なるチームが「オンラインでの支払いシステム」を開発した時に、同じ期間で1000行のコードで開発したのと、100行のコードで開発したのでは、どちらのチームがパフォーマンスがよいと言えるでしょうか。ほぼ同じ機能であるならば、開発時のコストはもちろん、その後の保守メンテナンスのことも考えれば、より少ない行数で実現できた方がよいことは疑いようがありません。最近のNo Code の流行にもあるように、全くコードを書かずに実現できれば、それが最も効率が良いとも言えます。

　LOC の問題点の一つは、単純な変数の代入も、複雑な算術演算ステートメントも、同じ1行でカウントされてしまうことにあります。この問題点を解決する一つのアイディアは、行の複雑度に応じて重み付けをすることですが、「17行目のステートメントが45行目のステートメントよりも2倍の重みを持っている」などと定量的に表現することは容易ではありません。LOC は、その名の通り単位「コードの行数」を数えただけのものであり、開発時間や、生産性や、コストに直接変換できるものではありません。

　このように、様々な問題をもつメトリクスではありますが、それでもなおLOC が有用な場面は多数あります。例えば、LOCの絶対量ではなく相対的な変化に注目してチームの開発フェーズの変化を知ることができます。前述の通り、LOCの値そのものはチームの生産性と必ずしも関連性があるとは言えませんが、同じプロジェクト、同じチームにおいて、チームの先週のLOCと今週のLOC を比較することで、増加傾向であれば「設計フェーズから実装フェーズに入った」とか、減少傾向であれば「実装が一段落してテストフェーズに入った」などと類推することができます。

　他には、LOC はテストや保守の基準値として使われることもあります。10万行のソフトウェアは、1万行のソフトウェアよりも保守やテストのコストがかかるのは同意できるところだと思います。バグの数をLOC で割ったものを「バグ密度」と定義し、ソフトウェア品質の基準値として使っているチームもあります。

　LOCの計測方法にはいくつかの定義があり、チームや組織で採用する場合は同じ定義を一貫して使うことが重要です。単純にテキストファイルとしての行数(Physical LOC)を使うこともありますが、多くの場合、空行とコメント行を除いた行数(Non-comment LOC: NLOC)や、NLOCからさらに、「2つの命令が書かれた行は2行と数える」、「括弧だけの行を除く」などの換算をした行数(Logical LOC: LLOC)を用いることが多いでしょう。コメントの行数をComment lines of program text: CLOC として計算し、ソースコード中のコメント密度を CLOC/LOC として定義し、一定以上を保つようなルールを設けているチームもあります。 

Halstead Volume

　ソースコードの規模を求めるメトリクスとしては、LOC (とその派生)が使われることがほとんどですが、Halstead Volume というメトリクスも一部で使われているので紹介します。例えば、Halstead Volume は、MS Visual Studio において、保守容易性を測定するための指標の入力値の一つとして使用されています。

　Maurice Howard Halstead は、1977年に出版した論文においてソフトウェアの複雑度の測定方法を提唱しました。その複雑度の計算に必要な値の一つが、ソフトウェアの規模の指標でHalstead Volume と呼ばれています。定義は以下の通りです。

　あるプログラムを、演算子またはオペランドとして分類されたトークンの集合として定義し、以下の値を計算します。

• η1 = 固有の演算子の数
• η2 = 固有のオペランドの数
• N1 = 演算子の総出現回数
• N2 = オペランドの総出現回数

ここで、プログラムのVocabulary (語彙) を η = η1 + η2 とします。プログラムのLength (長さ) を N = N1 + N2 とします。ηとN を使って、Halstead Volume は以下のように定義されます。

　Halstead は、他にもブログラムの複雑度(Difficultiy)や、作業量(Effort)、開発にかかる時間(Time required to program) などを定義していますが、Volume 以外のメトリクスに関しては経験的な(empirical)モデルと数学モデルとの関係が不明確であるとの批判も多いようです。

注意点

以下では、ソースコードの規模を測定する際に考慮すベきいくつかの注意点を挙げておきます。

プログラミング言語間の違い

同じようなソフトウェアを開発する際に、選択するプログラミング言語によってコードの規模が変わります。極端な話、LISP で書いた場合は、同じ動作でもJava とは異なる行数になるでしょう。異なるプログラミング言語が混在したプロジェクトにおいて、LOC からバグの数や工数の概算をするつもりであれば、プログラミング言語に応じてなんらかのファクターをかける必要があるかもしれません。

再利用コードの取り扱い

プロジェクトにおいて、車輪の再発明を防ぐために、過去のコードを利用したり、オープンソースのライブラリを組み合わせるのは一般的です。また、開発環境や導入しているフレームワークが自動的に生成するコードもあるでしょう。開発工数の見積もりなどで、コードの規模を測定する際は、そのような再利用コードを除外する必要があります。

再利用されたコードを数えることは、思ったより単純ではありません。例えば、NASA/Goddard’s Software Engineering Laboratoryでは、再利用のレベルを次のように定義しています(1995)。

1. 逐語的に再利用されている。ユニット内のコードがそのまま再利用されている。 
2. わずかに変更されている。25%以下のLOCが変更されていた。 
3. 大幅に変更されている。25%以上のLOCが変更された。 
4. 新規である。以前に建設されたユニットに由来するコードはない。 

完全なコピーではなく上記の2, 3 のように一部改変された再利用コードをプロジェクト全体から検出するにはツールが必要になります。Sider Labs の使用を検討して下さい。

上記のように、コードの規模を測定するには、使われているプログラミング言語や再利用の度合い、その他の要因への依存性を考慮しなければなりません。しかしながら、最も簡単に測定できる便利なメトリクスでもあります。賢く利用していきましょう。

The post ソフトウェアメトリクス2:ソースコードの規模 appeared first on Sider Labs Blog.

ソフトウェア開発チームは、迅速に行動しなければなりません。予算はますます厳しくなっています。タイムラインも短くなってきています。そして、クライアントは常により多くの機能を求めてきます。もしあなたのチームが最大限の能力を発揮できるようにしたいのであれば、可能な限り効率的に仕事をする必要があります。

ソフトウェア開発チームにとって、ブランチの作成方法は生産性に関わる一要素ですが、いわゆるベストプラクティスを採用してないケースも多いようです。結果として、多くの問題や余計な労力が発生している可能性があります。この記事では、生産性を向上させる9つの方法を紹介します。

0.ブランチとは何ですか？

ブランチとは、バージョン管理システム（Version Control System: VCS）で管理されているオブジェクトのコピーのことです。VCS内のコードベースは別名トランク(幹) とも呼ばれ、そこから異なる「ブランチ(枝)」が分岐しています。これらのブランチによって、ソフトウェア開発者は、コードベースを不安定化させることなく、分離して実験することができます。大規模なプロジェクトでは、開発者や品質保証など、多くの異なる役割が必要になります。ブランチを使うことで、これらの異なる役割を満たし、並行して開発することができます。一人の人間がブランチに変更を加えても、他のチームメンバーに影響を与えることはありません。

ブランチの利点は、多くの異なる人々が同時にプロジェクトに取り組むことができるということですが、ソフトウェアのブランチ化のベストプラクティスを持っていない場合、これは大きな頭痛の種になる可能性があります。

以下では、9つのベストプラクティスを紹介します。

1.ブランチング戦略をチームに伝える

まず、どのようなブランチング戦略を採用するかを決める必要があります。ソフトウェアチームが利用するブランチング戦略で、広く採用されているものは以下の3つです。

Git Flow はおそらく最もよく知られている戦略です。2010年に策定されたこの戦略では、master が本番用ブランチであり、develop がベースブランチとして扱われるとしています。feature-*、hotfix-*、release-*など、さまざまなサポートブランチを使用することもできます。Git Flow は非常に厳格なプロセスを作成しますが、これはマージやリリースにおける心理的な不安を和らげるのに役立つかもしれません。もしあなたのQAプロセスが厳格なものであれば、Git Flowはあなたにとって最高のブランチング戦略となるかもしれません。

コインの裏返しになりますが、Git Flowは開発が本番と同等ではないため、環境間の移行が必須になります。そのため、頻繁なリリースを行う継続的デリバリー(CD)や継続的インテグレーション(CI)は、Git Flowの下では困難になる可能性があります。また、Gitの履歴が読めなくなることもしばしばあります。

GitHub Flowは、Git Flowに比べてプロセスがはるかに簡素化されており、複数の異なる環境や同時バージョンの管理を必要としない小規模なチームにとっては、優れた選択肢となります。GitHub Flowでは、まずマスターブランチから始めます。作業が必要になるたびに、新しいブランチをチェックアウトします。作業内容を確認してマージする準備ができたら、master へのプルリクエストを開くだけです。マージされてmasterにプッシュされたら、理想的にはすぐにデプロイするべきです。

このブランチ戦略はCD/CIにはより親しみやすく、1つの本番環境で1つのバージョンを運用する場合には理想的です。本番環境で複数のバージョンが必要な場合は、この分岐戦略は向いていません。同様に、GitHub Flowでは、デプロイ、リリース、イシューなどに関しての取り決めがなく、本番コードが不安定になりやすい傾向があります。

Gitlab Flowは、より新しいブランチ戦略の一つで、特にサポートが必要な環境が複数ある場合に適しています。このブランチ戦略では、masterがベースブランチとなります。新しい機能を開発する際には、masterに直接コミットせずにmasterからコードを分岐させます。このブランチ戦略は、ドリフトを最小限に抑えるのに役立ちます。この戦略を使えば、git の履歴もすっきりして読みやすくなります。CD/CI を設定することもできます。

この戦略はGitHub Flowよりも複雑で、複数の本番バージョンを維持しなければならない場合はさらに複雑になる可能性があります。

チームに適した戦略を選択したら、その戦略をチーム全体に周知させましょう。フォルダやホワイトボードなど、チームが簡単に見て思い出すことができる場所に文書化します。チームがどのくらいの頻度で、どこからコードを分岐してマージすべきかをチームに知らせるようにしてください。戦略を一度伝えたからといって、誰もがそれを覚えているわけではありません。開発サイクル全体を通して、チーム全員が同じ考えを持っていることを常に確認してください。これは簡単なことのように思えるかもしれませんが、チームの成功には絶対に必要なことです。

2.作業の依存度を把握する

ソフトウェアの分岐の実践のもう一つは、依存関係を意識することです。自分の変更が他のチームやバージョンにどのような影響を与えるかを確認し、将来のマージを可能な限り容易にするような決定をしてください。また、どのブランチにコアコンポーネントを実装するのが最適か？どこが一番便利なのか? 関係者全員にとってリスクが少ないのはどこか? これらの優先度に関する質問に対する質問の答えを予めチームで共有しておくことで、納期が迫ってきたときの無用なストレスから解放されます。

依存関係の可能性を把握して予測することも、ソフトウェア分岐の最も重要なベストプラクティスの 1 つです。

3.マージの頻度を上げる

ブランチが多いチームもあれば、少ないチームもあります。しかし、ブランチの数に関係なく、ソフトウェアのブランチングのベストプラクティスでは、頻繁にマージすることでコードのチェックアウト時間を最小限に抑えることが求められています。コードがチェックアウトされる時間が長くなればなるほど、コードは孤立していきます。そして、孤立したコードになればなるほど、それは大きな潜在的問題となります。

コードがチェックアウトされている期間が長くなると、マージがどんどん難しくなります。ソフトウェア開発のライフサイクルが長い場合でも、毎日マージすることは有用です。しかし、多くのチームはこれを行っていません。もし毎日がチームにとって多すぎるのであれば、少なくとも週1回のマージから始めましょう。そうすることで、無用なコンフリクトを防ぐことができます。Sleeek ようなツールを用いて、チームメンバーのPush やマージの状況を可視化することも生産性向上に役立ちます。

4.バージョン管理システムを賢く選ぶ

今日では、多くの異なるバージョン管理システム(VCS) があり、それぞれに長所と短所があります。いずれを選択しても、選択したVCSがチームやプロジェクトが必要とするファイル数、コントリビューター数、ビルドの要求に対応できることを確認してください。VCS の中には、プロジェクトに有益な特殊なブランチ機能を持っているものもあります。

近年ではバージョン管理システムのディファクトスタンダードとえるのはGitですが、実際にはまだまだSubversion(以下、SVN)で管理をしている現場も多いと思われます。また、Git自体にもGitそのものや、Gitをコア機能にしたプラットフォームサービス(GitLab, GitHub, Bitbucket など)があります。時間をかけて、利用可能なさまざまなオプションを検討してみてください。プロジェクトが進行してしまった後で、バージョン管理システムが必要な要件を処理できないことに気づくのは避けたいものです。

5.変更の調整

複数の異なるブランチを統合することは、熟練した開発者にとっても困難なことです。時には何日もかかることもありますし、ソフトウェア開発の知識のすべてを要求されることもあります。このため、ソフトウェア開発のベストプラクティスのもう一つは、潜在的にリスクをもたらす可能性のあるプロジェクトの要素の変更を計画し、調整することです。これは、コアライブラリのような共有要素については特に重要です。

リスクを減らし、調整を高めるのに役立つテクニックはたくさんあります。変更の影響を議論するために、特定の会議を開くことができるかもしれません。これは、チーム全体を巻き込むのに役立ちます。もう一つの選択肢は、可能性のあるすべての実装ソリューションをブレインストーミングすることです。忘れていたことや考えていなかったことを思いつくかもしれません。また、プロジェクトの共有部分を担当する独立したチームを作ることもできます。いずれにしても、変更やマージに関しては、全員が同じ意識・戦略の上にいることが、ソフトウェアブランチングで重要な部分になります。

6.開発プロセスをシンプルにする

他のほとんどのものと同様、ソフトウェアの分岐はシンプルにしておくと最もうまくいきます。このソフトウェア開発のベストプラクティスを実装するためには、ブランチは必要な期間のみ存在するようにし、無用に長生きさせないようにします。堅牢な VCS を持っている場合でも、ブランチの数を少なくすることは、長期的に役立つソフトウェアブランチのベストプラクティスの一つです。ブランチの数が多ければ多いほど、多くの問題が発生します。

同様に、マージもシンプルにしましょう。チーム内で、マージ間の時間を短縮する方法を見つけてください。チームが同時に作業するコードを分離するためにフォルダを構成することもできます。データベース内のスクリプトを継続的にアップグレードしていると、スクリプトのバージョンの競合に遭遇することがあります。これは、別々のブランチで作業している2つのチームが、同じデータベースバージョンへのスクリプトアップグレードを書いたが、データベースの変更が異なる場合に発生する可能性があります。これを防ぐには、チームごとに異なるバージョン範囲を予約するだけです。

システムが大きくなってきたら、異なるコンポーネントを別のブランチに分けて、 バイナリ形式にコンパイルしてみてください。これにより、コンポーネントのコードが一つの場所に保持され、マージを必要としないことを確認するのに役立ちます。また、コンポーネントは一度だけコンパイルされるので、ビルドはより速くなります。

どのような方法で実装するにしても、チームのために開発するにしても、シンプルであればあるほど良いです。

7.トランクの品質を守る

森の中では、いくら木の枝の手入れを頑張っていても、幹の手入れをしなければ木は生きられません。ソフトウェア開発でも同じことが言えます。開発チームは個々の枝に関心を持ちすぎて、トランク(幹) のことを忘れてしまうことがあります。すべてのコミットを高品質に保つことで、トランク(=メインライン) を守りましょう。ビルドとテストのプロセスの一部として、コードレビューとコミット前の継続的インテグレーション(CI)を使用してください。メインラインがいつでも再利用できるように最善を尽くしましょう。

8.継続的インテグレーションを促進する

アクティブなブランチごとに個別のCIプロセスを持ちましょう。これにより、各ブランチのメンテナンスが容易になり、必要に応じて変更が容易になります。CI なしでは、ブランチはマージせずに無駄に生存してしまうかもしれません。これは、マージに関連するバグの発見がプロセスの中で遅すぎることにつながり、不必要な作業やストレスの原因になります。

9.タスクが完了するまでの見積もりにマージ作業を含める

最高のアジャイルソフトウェア開発チームは、機能やプロジェクトがいつ終了したとみなされるかを決定するために、完了の定義(Difinition of Done: DoD)を使用しています。この定義には、マージ活動のための時間を含めることを忘れないでください。これは、プロジェクトを進めていく上で、潜在的な誤解を避けるのに役立ちます。 

上記のソフトウェア分岐のベストプラクティスは、あなたとあなたのチームが可能な限り最高のプロジェクトを作成するのに役立つように設計されています。すぐにでも試してみましょう！

The post 成功への分岐点 — ソフトウェアブランチのベストプラクティス — appeared first on Sider Labs Blog.

いつもSiderをご利用いただきありがとうございます。

11月12日木曜日、メンテナンスのため sider.review は午後9時（JST）から約1時間ダウンします。

この時間、GitHub上で作成されたプルリクエストに対する解析が行われなくなるため、GitHub上でのワークフローに影響が出る恐れがあります。 メンテナンス中に作成されたプルリクエストをメンテナンス後にSiderに解析させるには、新しいコミットをpushするか、プルリクエストをリオープンするようお願いいたします。

メンテナンスの進捗は、随時ステータスページにて確認いただけます。

ご不便をおかけしますが、ご理解のほどよろしくお願いいたします。

The post 2020年11月12日（木）データベースメンテナンスのお知らせ appeared first on Sider Labs Blog.

こんにちは。いつもSiderをご利用頂きありがとうございます。
SiderがMISRA C コーディングガイドラインの解析に対応いたしましたので、ご紹介します。
これにより、プルリクエスト単位で、そのプルリクエスト内で修正されたソースコードがMISRA C:2012に違反していないかを常時チェックすることが出来ます。

SiderではCppcheckという解析エンジンを用いております。そのエンジンのアドオンmisraを有効にする記載を、Siderの設定ファイルに記載していただくことでご利用いただけます。

sider.yml

linter:
  cppcheck:
    addon:
      - misra

MISRA C とは？

MISRA C とは Motor Industry Software Reliability Association (MISRA) が策定しているC言語のコーディングガイドラインです。
組み込み制御システムや車載ソフトウェアといった高い水準の安全性を求められるソフトウェアの開発者向けに、ガイドラインのベストプラクティスを提供しています。

MISRA C はもともと自動車分野向けに策定されました。しかし、今日では鉄道/航空宇宙/医療機器などの幅広い組み込みソフトウェア分野でも採用されています。
このような高い水準の安全を求められる開発現場で、安全性/可搬性/信頼性を確保するために MISRA C ガイドラインを利用する場面が増えております。

Siderの Cppcheck MISRA C アドオン対応

Siderは既にC/C++言語向けにCppcheckのサポートしておりましたが、今回、 MISRA C アドオンに対応いたしました。

Cppcheckの MISRA C アドオンでルールのメッセージを表示するためには、使用者ごとにMISRAからガイドラインのドキュメントを購入する必要があります。
しかし、このたび、SiderはMISRAと契約を締結しましたので、ルールのメッセージを当プロダクトに組み込んで提供を開始いたしました。
なお、そのルールのメッセージは無制限には公開できないため、解析対象がprivateなレポジトリの場合のみ表示されます。

もし、複数の解析器を有効にして実行していたり、報告されたissueの数が多い場合には、「高度な検索」をクリックしてフィルタしてください。ツールとして Cppcheck、そして所望のルールIDを適用することで、 MISRA C の結果のみを表示することができます。

MISRA C:2012 のSiderのカバー範囲

SiderではCppcheckの MISRA C アドオンを利用して、MISRA C:2012 の143件のルールのうち99件をサポートしています。カバーしていない44件ほどはSiderではチェックすることは出来ません。
それらの項目の多くはコンパイルが必要なためであり、迅速に解析を行うSiderのサービス性質上提供が難しいため、現時点ではそれらを提供する予定はありませんが、欠落しているそれらのルールについての一部はgccなどを使っていただくことで補っていただく事ができます。

Sider（内のCppcheck MISRAアドオン）でPull Request・Merge Request単位を高速に解析し、必要に応じて、CI/CDなどでコンパイラをあわせてご利用いただき、カバー範囲を増やしていただくのが良いかと思います。

他社のMISRA Cチェック機能を持つ製品との比較・使い分けについて

MISRA C設計標準規格をチェックする製品は非常に多く存在しています。よく知られているものだと、Synopsis社のCoverity静的解析ソリューションや、PARASOFT社のC++test、Micro Focus社のFortifyなどがあります。それらとSiderの違いについて2軸で説明させていただきます。

アジャイル開発、GitHub/GitLabを用いた開発に最適化されたSider

Siderは比較的新しい製品です。現時点では、ローカルでのコマンドライン実行やIDEとの連携、Jenkins（CI/CDサーバー）上での実行などには対応していません。一方で、GitHubやGitLabのPull Request・Merge Requestとの連携に対応しています。
他社製品であればQAフェーズの前工程やQAフェーズなど、開発工程の後半で利用することが主だった利用シーンですが、Siderの場合は最初のコミットから、差分だけを確認をして、MISRA規約違反のコードを発見、修正していくことが出来ます。そのため、他社様の製品をすでにご利用頂いている環境にSiderを導入いただいた場合、それらの製品で後工程で確認する際に、Siderが指摘した分の内容が減るため、後ろの工程での修正や対応時間などを減らすことが出来ます。

開発者は昔に書いたコードを再度確認して修正するのではなく、ついさっき書いたコードに対して、Pull Request・Merge Request単位で確認をし、迅速に修正を行うことが出来ます。それにより高い生産性でMISRA準拠のコードを書くことが出来ます。

非常に安価。1500円から利用可能。追加費用もなし

Siderは1ユーザーあたり月額1500円の利用料でご利用いただけます。クラウド版の場合、サーバーコストも掛かりませんので、非常に安価にご利用いただけます。また、インストールも数クリックと、先述の通り設定ファイルを数行書くだけで済むため、総合的に様々な面でコストは非常に低いです。

1プロジェクトあたり数百万円単位の製品が多い中、プロジェクト数は無制限、ユーザーあたり1500円（100名の場合でも月間15万円、年間180万円でプロジェクト数無制限）と非常に安価であるため、ぜひご検討を頂ければ幸いです。

Pull RequestやMerge Requestだけでなくプロジェクト全体を検査したい

MISRA C規格に準拠しているかの確認についてはおそらく、Pull RequestやMerge Request単位だけでなく、プロジェクト・リポジトリ全体を検査したいというニーズもあるかと思います。
2020年12月より「ブランチ（Mainブランチや任意に指定したブランチ）」を解析する機能の提供を開始しました。

現在のリポジトリ全体に対し解析をかけ、規約・規格に反しているコードの一覧を表示、1つずつ解消していく、などの使い方ができます。

おわりに

Siderはユーザ様のニーズに合わせて様々な発展・機能追加や対応言語追加などを行っております。
ぜひSiderをご利用いただき、また、なにかご要望がありましたら下記製品サイトの画面右下のチャットよりお声がけください。

sider.review

今後ともSiderをどうぞよろしくお願いいたします。

The post SiderでMISRA C規格準拠チェックが可能に。組み込みソフトウェアの開発にSiderによるMISRA C/C++チェックを appeared first on Sider Labs Blog.