SonarQube؛ از Scope و Profile تا Quality Gate

SonarQube وقتی ارزش می‌سازد که یک «ماشین سبزکنندهٔ Build» نباشد. خروجی تحلیل استاتیک Signal است؛ اعتبار آن به نسخه و Edition، زبان و Analyzer، Scope، Quality Profile، تعریف New Code، Coverage report، Triage و Quality Gate وابسته است. اگر هرکدام مبهم باشد، Gate سبز می‌تواند فقط نتیجهٔ اسکن‌نشدن فایل‌ها یا واردنشدن Report باشد.

این راهنما یک SonarQube Operating Contract برای تیم توسعه و QA می‌سازد: Inventory، PoC، Pipeline state، تنظیم Profile/Gate، New Code baseline، Scope/Exclusion، Coverage import، Issue lifecycle، Upgrade rehearsal و Evidence. هیچ Server، Repository، Token، License یا Pipeline واقعی در آزمایش استفاده نمی‌شود.

خلاصهٔ اجرایی SonarQube برای QA و توسعه

• نسخه، Edition/Community Build، Analyzer، Scanner، JDK و Plugin را در هر Run ثبت کنید.
• Quality Profile با Quality Gate فرق دارد؛ اولی Rule set و دومی Conditions را تعریف می‌کند.
• New Code baseline و Analysis Scope مخرج Gate را تغییر می‌دهند؛ آن‌ها را Policy نسخه‌دار بدانید.
• SonarQube Coverage را تولید نمی‌کند؛ Report ابزار بیرونی را Import می‌کند.
• Scanner success، Compute processing و Gate status سه State متفاوت‌اند.
• Accepted/False positive/Exclusion تصمیم‌های قابل‌ممیزی می‌خواهند، نه راه میان‌بُر برای سبزشدن.
• Gate سبز، تصمیم کامل Release نیست و تست پویا، Business outcome و Operations را پوشش نمی‌دهد.

Source snapshot → tests/reports → scanner → server processing → measures/issues → quality gate → bounded decision

SonarQube چه مسئله‌ای را حل می‌کند؟

SonarQube و Community Build کد را با Ruleهای Analyzer بررسی و Issue/Measure تولید می‌کنند. این Capability برای Feedback زودهنگام، Trend، Triage و Policy مفید است؛ اما اجرای برنامه، رفتار کاربر، صحت کسب‌وکار، Dependency runtime و کل سطح حمله را مشاهده نمی‌کند. برای مبانی روش به راهنمای تحلیل استاتیک کد از Alert تا Quality Gate مراجعه کنید.

• Rule violation و code location
• Maintainability/Reliability/Security signal بر حسب Mode و Rule
• Security Hotspot نیازمند Review، نه Vulnerability قطعی
• Duplication/complexity/size measures
• Imported coverage/test execution data
• New-code/overall-code views و Gate result

SonarQube چه چیزی را اثبات نمی‌کند؟

نبود Issue به معنای نبود Bug یا Vulnerability نیست. Ruleها الگوهای قابل‌تحلیل را می‌بینند و False negative ممکن است. Coverage بالا هم Assertion و Oracle را اثبات نمی‌کند. Quality Gate تنها Conditions پیکربندی‌شده روی Measures همان Analysis را ارزیابی می‌کند؛ Availability، UX، داده، Authorization runtime و Release risk بیرون آن می‌مانند.

Rejected promise:
SONARQUBE_ZERO_BUG_ZERO_VULNERABILITY_100_COVERAGE_ALL_CODE_QUALITY_RELEASE_READY

نسخه‌های جاری در اوت ۲۰۲۶

صفحهٔ رسمی Download SonarQube در Snapshot بررسی‌شدهٔ ۱۴ اوت ۲۰۲۶، SonarQube Server ۲۰۲۶.۱ LTA و Community Build ۲۶.۷.۰.۱۲۴۷۷۱ را نمایش می‌دهد. Fast release با LTA یکی نیست و Featureها میان Community Build و Editionها متفاوت‌اند. پیش از هر تصمیم، صفحهٔ جاری، Entitlement، زبان و Support lifecycle را دوباره بررسی کنید.

version_identity:
product + edition/build + exact version + release channel + support status
+ server JDK/DB + scanner + analyzer/plugin set + license/entitlement snapshot

Release سریع یا LTA؟

Releaseهای سریع Feature و Fix تازه می‌آورند؛ LTA پنجرهٔ پشتیبانی طولانی‌تر و ریتم ارتقای متفاوت دارد. انتخاب را با Language support، Rule need، Security fix، Plugin compatibility، JDK/DB requirement، Change capacity و Rollback rehearsal انجام دهید. «همیشه آخرین» و «هرگز از LTA خارج نشو» هر دو بدون Context نسخهٔ خوبی نیستند.

مسیر ارتقا را از مستند نسخه بخوانید

یادداشت رسمی LTA تا LTA برای ۲۰۲۶.۱ می‌گوید ۲۰۲۵.۱ LTA می‌تواند مستقیم به ۲۰۲۶.۱ LTA ارتقا یابد، اما ۹.۹ LTA ابتدا به ۲۰۲۵.۱ نیاز دارد. این مثال را قانون همیشگی نکنید؛ Source/Target دقیق، Deprecation، JDK، DB و Plugin را از همان Release notes و Update path جاری بگیرید.

• Source/target version و Channel
• Database/JDK/OS requirements
• Plugin/Analyzer compatibility
• Removed API/property/rule behavior
• Backup و Restore verification
• Staging rehearsal و مدت Downtime
• Pre/post analysis delta و Rollback trigger

Operating Contract را قبل از نصب بنویسید

Contract باید بگوید چه Repositoryهایی داخل Scope‌اند، چه کسی Profile/Gate/Exclusion را تغییر می‌دهد، Token کجا نگهداری می‌شود، چه Stateای Merge را می‌بندد، Triage چه SLAای دارد، Upgrade و Restore چگونه آزموده می‌شود و Evidence چقدر نگه می‌ماند. Tool بدون Owner به داشبوردی منقضی تبدیل می‌شود.

contract_id: SQ-SYN-v1
owners: platform / language / triage / gate / risk
scope: fictional repository only
review: version, rule, policy or architecture change

Hard Gateهای Eligibility و Access

پیش از PoC، زبان/Framework، Branch/PR feature، Scanner، CI provider، SSO، گزارش، Edition، License، Support، Download/registry access و Storage/backup را بررسی کنید. برای ایران، قیمت، ارز، پرداخت، قرارداد و دسترسی را با تاریخ ثبت کنید؛ از هویت/نشانی جعلی، حساب قرضی، تغییر مکان، Proxy ناشناس یا TLS bypass استفاده نکنید.

• ELIGIBLE: نیاز و Feature در نسخه/Edition تأیید شده است.
• TRIAL: PoC محدود با داده و Repository ساختگی ممکن است.
• HOLD: License/Access/Language/Owner/Continuity نامعلوم است.
• EXIT: Export، Migration و نگهداری Evidence تعریف نشده است.

Project و Analysis Identity

Project key، Repository/commit، Branch/PR target، Build، Scanner، Server، Profile، Gate و New Code definition را به هم وصل کنید. تحلیل روی Commit اشتباه یا Target branch قدیمی می‌تواند دقیق اجرا شود ولی پاسخ سؤال غلط را بدهد. Shallow/missing SCM history و Generated code نیز classification را تغییر می‌دهند.

analysis_id:
project_key + commit_sha + branch/pr + target_sha + build_id
+ server_version + scanner_version + config_hash + report_hashes

Quality Profile با Quality Gate فرق دارد

Quality Profile می‌گوید کدام Ruleها اجرا شوند و برای هر زبان جداست. Quality Gate می‌گوید نتیجهٔ Measureها با Conditions مصوب Pass یا Fail است. Profile کوچک می‌تواند Gate را سبز کند چون Issue تولید نشده؛ Gate سخت نیز با Scope ناقص بی‌معناست. هر دو را همراه نسخه و Association ثبت کنید.

لایه	پرسش	Artifact	خطر Drift
Analyzer	کد چگونه فهمیده می‌شود؟	version/plugin/language	Rule behavior change
Quality Profile	چه Ruleهایی فعال‌اند؟	profile/rules/params	inheritance/update
New Code	محدودهٔ تغییر چیست؟	baseline definition	wrong version/branch
Analysis Scope	چه فایل‌هایی دیده می‌شوند؟	sources/tests/exclusions	shrunk denominator
Quality Gate	چه Conditionsی Fail می‌کنند؟	gate/thresholds	silent reassociation

Quality Profile را Governance کنید

مستند رسمی Quality Profiles آن را مجموعهٔ Ruleهای اعمال‌شده برای یک زبان تعریف می‌کند. Built-in profile، Custom profile و Inheritance رفتار متفاوت دارند؛ Upgrade می‌تواند Ruleهای built-in را تازه کند. تغییر Rule/Severity/Parameter باید دلیل، Owner، Change request، نمونهٔ موافق/مخالف و Rollback داشته باشد.

1. زبان و نسخهٔ Analyzer را Pin کنید.
2. Profile association و Parent را ثبت کنید.
3. Rule additions/removals/parameter delta را Diff کنید.
4. Corpus محلی Known-positive/negative را دوباره Scan کنید.
5. Noise، missed signal و Triage cost را بازبینی کنید.
6. Change را با Owner و تاریخ مؤثر منتشر کنید.

Quality Gate را Policy قابل‌توضیح بسازید

مستند رسمی Quality Gates Gate را مجموعه‌ای از Conditions روی Measures می‌داند. Built-in یا Custom بودن، New/Overall scope، Metric، Operator و Threshold را ثبت کنید. رفتار پیش‌فرض small-change برای Coverage/Duplication و قابلیت override را در نسخهٔ خود بررسی کنید؛ یک PR کوچک ممکن است آن Conditionها را اعمال نکند.

• Condition چه Risk claimی را نمایندگی می‌کند؟
• Denominator و minimum sample چیست؟
• Tool/report missing چه Stateی دارد؟
• Exception چه Owner/Expiryای دارد؟
• Gate failure Merge، Pipeline یا فقط Notice را چه‌طور تغییر می‌دهد؟
• چه شواهدی بیرون SonarQube لازم است؟

Gate سبز، تصمیم کامل Release نیست

Gate تنها Conditionهای تعریف‌شده روی Analysis را می‌سنجد. Release به تست‌های Unit/Integration/E2E، Security controls، migration، data، performance، resilience، operations و Product risk نیز وابسته است. SonarQube می‌تواند یک Control در Release policy باشد، نه جایگزین کل آن. برای CI security evidence به راهنمای DevSecOps رجوع کنید.

New Code definition مخرج سیاست است

مستند Quality standards and new code گزینه‌های Previous version، Number of days، Specific analysis و Reference branch را توضیح می‌دهد. در PR، تغییر نسبت به Target branch مبناست. گزینه را با Release cadence و Branch model هماهنگ کنید؛ projectVersion یا Reference اشتباه می‌تواند Debt را ناگهان داخل/خارج New Code ببرد.

new_code_contract:
definition_type + value/reference + effective_scope + owner
+ change_reason + expected baseline + verification query

PR Analysis چه چیزی را نمی‌بیند؟

PR analysis عمدتاً روی تغییر نسبت به Target متمرکز است و Availability آن به Edition/Integration وابسته است. Ruleهای file-level یا Issue backdating ممکن است تنها پس از تحلیل Target branch آشکار شوند. بنابراین PR Gate را با Branch analysis جایگزین نکنید و Target/base identity، fetch depth و post-merge run را ثبت کنید.

Analysis Scope: مهم‌ترین Denominator پنهان

Sources، Tests، Generated، Vendor، Migration و Exclusionها تعیین می‌کنند چه چیزی تحلیل شود. مستند Scope exclusion نشان می‌دهد Coverage و Duplication exclusions جدا هستند و CI parameter می‌تواند بر UI اولویت داشته باشد. هر Exclusion را least-scope، Reviewable و Expiring کنید.

• glob/pattern و base directory
• source-versus-test classification
• generated/vendor rationale
• coverage/duplication/issue-specific exclusion
• configuration precedence و effective value
• owner/approval/expiry
• file-count/line-count delta before-after

scope_receipt:
discovered_files → language_classified → excluded_by_reason → analyzed_files
gate cannot be read without this denominator.

Exclusion و NOSONAR بدهی نامرئی نسازند

Inline suppression می‌تواند همهٔ Issueهای خط را اکنون و در آینده پنهان کند؛ Broad glob نیز کل Directory را خارج می‌کند. ترجیح با اصلاح Rule/Profile یا Exclusion دقیق و مستند است. Inventory suppression را دوره‌ای Audit کنید و با تغییر Analyzer دوباره اعتبارسنجی کنید.

Coverage از ابزار تست می‌آید

مستند Test coverage parameters صریح است: SonarQube Server خودش Coverage report تولید نمی‌کند؛ ابزار بیرونی Report می‌سازد و Scanner آن را Import می‌کند. Format/path، working directory، source mapping، merge strategy و Report hash را ثبت کنید. Report missing را ۰٪ یا Pass تفسیر نکنید.

coverage_health:
producer_ran + tests_passed? + report_exists + format_valid
+ source_paths_match + report_imported + expected_file_count

Coverage فقط نسبت اجرای ساختاری را نشان می‌دهد. برای Denominator، Branch/line، Risk و محدودیت به راهنمای پوشش تست از Code Coverage تا Risk Evidence بروید.

Test Execution با Coverage یکی نیست

Coverage می‌گوید کدام ساختار کد هنگام Run لمس شده؛ Test execution می‌گوید کدام تست اجرا و با چه نتیجه‌ای تمام شده است. یکی بدون دیگری کامل نیست و هیچ‌کدام Oracle quality را اثبات نمی‌کند. Fail/Skip/Timeout، flaky retry و Report truncation را جدا نگه دارید.

Signal	Source	پرسش	Gap
Static issues	Analyzer/rules	چه patternی نقض شده؟	runtime/business
Coverage	external coverage tool	چه ساختاری اجرا شده؟	assertion validity
Test execution	test runner	کدام تست چه شد؟	unmodeled risk
Gate	configured conditions	Policy فعلی پاس است؟	non-configured controls

Scanner success با Gate success فرق دارد

Scanner می‌تواند Report را بسازد/ارسال کند و با موفقیت تمام شود، درحالی‌که پردازش Server هنوز صف است یا بعداً Fail می‌شود. Pipeline باید Analysis task ID را دنبال کند و Processing status و Gate status را دریافت کند. Timeout انتظار، Server unavailable، task canceled یا stale result همگی UNKNOWN/HOLD هستند، نه سبز.

pipeline_state:
SCAN_FAILED | PROCESSING | PROCESSING_FAILED | GATE_ERROR | GATE_OK | STALE | UNKNOWN
Only GATE_OK is tool-policy pass; none is a full release verdict.

Token و Secret را در Command/Log نگذارید

Token را با حداقل Scope، Secret store، masking، expiry و rotation مدیریت کنید. Command-line argument و Debug log ممکن است در process list یا CI artifact دیده شوند. Test کنید Failure message، scanner dump، webhook و PR decoration Secret را افشا نکند. Repository fork/untrusted PR نباید به Credential پرقدرت دسترسی یابد.

Issue، Finding قطعی نیست

Issue به Rule، Analyzer version، location و context وابسته است. ابتدا applicability و path را بررسی کنید؛ سپس Impact، exploitability/likelihood یا maintainability context را با Owner مشخص کنید. Security Hotspot درخواست Review است. Triage باید Fix، False positive، Accepted یا Rule/Profile correction را با Evidence و اختیار جدا کند.

1. Analysis/commit/rule identity را تثبیت کنید.
2. Code path و secondary locations را بخوانید.
3. True/false/uncertain applicability را مستند کنید.
4. Impact و compensating control را جدا بسنجید.
5. Owner/Disposition/expiry را ثبت کنید.
6. Fix را با re-analysis و regression evidence ببندید.

Accepted و False Positive اثر Gate دارند

مستند رسمی Editing issues می‌گوید Accepted و False positive در Quality reports/ratings نادیده گرفته می‌شوند و می‌توانند Gate مرتبط را تغییر دهند. بنابراین Accepted معادل «حل شد» نیست؛ Risk record، دلیل، Owner و Expiry بیرونی لازم است. False positive نیز Rule counterexample و Reviewer می‌خواهد.

disposition:
FIX | FALSE_POSITIVE(evidence) | ACCEPTED(risk owner, expiry)
| PROFILE_CHANGE(corpus) | SCOPE_CHANGE(denominator receipt)

Rule Upgrade یک Experiment است

Upgrade ممکن است Rule تازه، Deprecated، Severity، taint engine یا parser behavior را تغییر دهد. یک Corpus محلی از true positive، false positive، edge syntax و representative modules بسازید. نسخهٔ قدیم/جدید را روی Snapshot یکسان مقایسه و New/Fixed/Moved issue را Triage کنید. اختلاف خام تعداد، بهبود یا افت کیفیت را ثابت نمی‌کند.

برای Operating model چند ابزار امنیتی، راهنمای عملیاتی‌سازی ابزارهای AppSec مکمل است.

Metricها را بین زبان/تیم مقایسه نکنید

Complexity، duplication، remediation effort، issue count و LOC به Language، Analyzer، Profile، Scope و Architecture حساس‌اند. رتبه‌بندی Developer یا تیم با آن‌ها Gaming می‌سازد. Trend را فقط پس از تثبیت Measurement contract بخوانید؛ Configuration change را روی نمودار Annotate کنید و Uncertainty را گزارش دهید.

Maintainability را با Change Trial تکمیل کنید

Code smell یا Cognitive complexity Signal است، نه زمان قطعی نگهداری. برای Claim نگهداری‌پذیری، یک تغییر محدود را با Build time، touched modules، defect/regression، review effort و recovery مشاهده کنید. راهنمای تست قابلیت نگهداری این مکمل رفتاری را توضیح می‌دهد.

SonarQube جای SCA، DAST یا Test runner نیست

قابلیت دقیق به Edition، زبان و Rule set بستگی دارد. Static/taint/secret/IaC signal را با Software Composition Analysis، Dynamic testing، runtime telemetry، manual review و business tests اشتباه نگیرید. راهنمای ابزارهای SAST/DAST/SCA مرز هر دسته را شرح می‌دهد.

PoC را با Truth Set محلی اجرا کنید

• Repository مصنوعی با زبان/Build مشابه
• Known-positive Rule cases و benign controls
• Generated/vendor/test/source classification
• Coverage/test-report happy و missing/malformed
• PR/branch/new-code baseline cases
• Scanner/server/gate failure states
• Triage time و reproducibility
• Upgrade/export/restore/exit rehearsal

PoC outcome = signal validity + coverage denominator + operational health
+ triage cost + access/license continuity + exit feasibility

Upgrade rehearsal و Rollback

1. Inventory و supported path را Freeze کنید.
2. Backup را بگیرید و Restore را در محیط مجاز اثبات کنید.
3. Plugin/JDK/DB compatibility را Resolve کنید.
4. Config/Profile/Gate/Scope snapshots را Export کنید.
5. Representative corpus را قبل/بعد Analyze کنید.
6. Delta و Pipeline integration را Triage کنید.
7. Downtime، cutover، rollback trigger و Owner را تمرین کنید.

هیچ Upgrade command عمومی در این مقاله ارائه نمی‌شود؛ ترتیب و ابزار به Source version، deployment و مستند رسمی وابسته است. برای Toolchain/TCO/Exit به راهنمای انتخاب Toolchain تست مراجعه کنید.

Evidence Pack هر Analysis

بخش	فیلدها	هدف
Source	project/repo/commit/branch/target	هویت سؤال
Engine	server/scanner/analyzers/JDK	بازتولید
Policy	profile/gate/new-code/scope hashes	تفسیر نتیجه
Reports	coverage/test hashes/import health	اعتبار مخرج
Outcome	task/gate/issues/accepted/exceptions	Decision trail
Operations	timestamps/duration/retention/redaction	Audit و حریم

evidence_id: SQ-EV-SYN-09
analysis_state: PROCESSING_FAILED
gate_state: UNKNOWN
decision: HOLD
reason: no processed measures exist

سناریوی ایرانی کاملاً مصنوعی

یک Repository خیالی فروشگاه فارسی با فایل‌های TypeScript و Java، ارقام فارسی/عربی/لاتین، ی/ی، ک/ک، ZWNJ، RTL/LTR/Bidi، مبلغ canonical IRR و display-only تومان دارد. دو Manifest فرضی برای ۲۰۲۵.۱ و ۲۰۲۶.۱ فقط روی کاغذ مقایسه می‌شوند. هیچ Source واقعی، Developer، Server، Token، License، CI یا اتصال شبکه وجود ندارد.

• ۱۲ فایل ساختگی؛ ۸ source، ۳ test، ۱ generated
• دو Quality Profile hash فرضی
• یک Scope exclusion منقضی
• Coverage report missing در Run دوم
• چهار Issue از پیش‌نوشته، نه خروجی Analyzer
• Gate فقط پس از اعتبار Measurement قابل‌خواندن است

آزمایش آفلاین SYN-SONARQUBE-IR-۰۱

Checker سطحی با دیدن Gate سبز، پوشش ۱۰۰٪ و صفر Issue آمادهٔ Release اعلام می‌کند. Checker قراردادمحور ۹۴۴ Control گروه‌بندی‌شده را برای Identity، Scope، Rule، Profile، New Code، Report health، Processing، Triage، Upgrade، Evidence و Safety می‌سنجد و چون Coverage report هویت ندارد نتیجه را Hold می‌کند.

lab_id: SYN-SONARQUBE-IR-01
execution/network/server/repository: none
superficial: SONARQUBE_ZERO_BUG_ZERO_VULNERABILITY_100_COVERAGE_ALL_CODE_QUALITY_RELEASE_READY
contract: HOLD-944

Exit Criteria آزمایش

1. Version/Edition/Engine و Source identity کامل است.
2. Profile/Gate/New Code/Scope hash ثبت است.
3. Coverage/Test reports producer و import health دارند.
4. Processing، Gate و Release verdict یکی نشده‌اند.
5. Accepted/False positive/Exclusion دلیل و Owner دارند.
6. هیچ Person score یا تصمیم واقعی ساخته نشده است.

NO_REAL_REPOSITORY_SOURCE_CODE_DEVELOPER_ACCOUNT_TOKEN_SECRET_LICENSE_SERVER_CI_PIPELINE_PRODUCTION_MERGE_RELEASE_OR_PERSON_PERFORMANCE_DECISION_PASS
READY_FOR_SONARQUBE_OPERATING_CONTRACT_REVIEW-0

ضدالگوهای رایج SonarQube

• Gate سبز به‌عنوان Zero Bug/Secure/Release ready
• Quality Profile و Gate به‌عنوان یک مفهوم
• New Code baseline مبهم یا projectVersion دست‌کاری‌شده
• Exclusion گسترده برای سبزکردن Coverage
• Coverage report missing به‌عنوان ۰٪ یا Pass
• Scanner exit صفر بدون انتظار Processing/Gate
• Accept/False positive/NOSONAR بدون Evidence
• مقایسهٔ Issue/complexity بین زبان‌ها و افراد
• Rule upgrade بدون Corpus و Delta review
• Token در command/log یا دسترسی Fork
• فرض پشتیبانی Feature در همهٔ Editionها
• ارتقای Production بدون Restore/Rollback rehearsal

برنامهٔ ۳۰ روزهٔ استقرار کنترل‌شده

1. هفتهٔ اول: Eligibility، Version/Edition، Language و Contract owners را قطعی کنید.
2. هفتهٔ دوم: Truth Set، Scope receipt، Profile/Gate/New Code policy و Report health را بسازید.
3. هفتهٔ سوم: CI state machine، Triage و Exception/expiry را در PoC مصنوعی تمرین کنید.
4. هفتهٔ چهارم: Delta، Noise، missed signal، TCO، Access و Exit را بازبینی و KEEP/ADAPT/STOP کنید.

چک‌لیست نهایی Owner

• Version/Edition/Channel/Support/Entitlement ثبت شده است.
• Server/JDK/DB/Scanner/Analyzer/Plugin سازگارند.
• Source/branch/target/build identity دقیق است.
• Profile و Gate Association نسخه‌دارند.
• New Code baseline با cadence/branch model هم‌خوان است.
• Scope receipt و همهٔ Exclusionها Owner/Expiry دارند.
• Coverage/Test report health قبل از Metric بررسی می‌شود.
• Processing failure/timeout/stale هرگز Pass نیست.
• Issue/Hotspot/Triage/Accepted/False positive مرز روشن دارند.
• Secret، Log، Access و Retention کمینه‌اند.
• Upgrade با Corpus/Restore/Rollback تمرین شده است.
• Gate فقط یک Control در Release policy است.

برای جایگاه SonarQube در خانوادهٔ تست‌های ایستا، راهنمای تست استاتیک را بخوانید.

پرسش‌های متداول

SonarQube چه تفاوتی با اجرای تست دارد؟

SonarQube عمدتاً Source و Artifactهای تحلیل را با Ruleها بررسی می‌کند؛ Test runner برنامه را اجرا و نتیجه/coverage می‌سازد. SonarQube می‌تواند Report را Import کند، اما خودش کیفیت Assertion یا Business outcome را اثبات نمی‌کند.

Quality Profile و Quality Gate چه فرقی دارند؟

Profile مجموعهٔ Ruleهای فعال برای هر زبان است و تعیین می‌کند چه Signalهایی تولید شوند. Gate Conditions روی Measure/Issueهای حاصل را ارزیابی می‌کند. Scope و New Code نیز مخرج هر دو نتیجه را تحت‌تأثیر قرار می‌دهند.

آیا Gate سبز یعنی کد آمادهٔ انتشار است؟

فقط یعنی Conditions پیکربندی‌شده برای Analysis معتبر فعلی Pass شده‌اند. Release به Evidenceهای دیگری مانند تست runtime، امنیت، migration، performance، resilience، operations و Risk decision نیاز دارد.

چرا Coverage در SonarQube نمایش داده نمی‌شود؟

SonarQube Coverage را تولید نمی‌کند. باید ابزار تست Report سازگار بسازد، پیش از Scanner اجرا شود و Path/format/source mapping درست پیکربندی گردد. ابتدا وجود/هویت/Import report را بررسی کنید، سپس درصد را تفسیر کنید.

برای ایران Community Build بهتر است یا Edition تجاری؟

پاسخ عمومی ندارد. Language/PR/branch/security/report/SSO نیاز، License/Support، پرداخت و دسترسی قانونی، TCO، Upgrade، Backup و Exit را با تاریخ مقایسه کنید. هویت یا مکان جعلی و TLS bypass راه‌حل قابل‌قبول نیست.

جمع‌بندی: از Dashboard به Control قابل‌ممیزی

SonarQube زمانی Control قابل‌اعتماد است که Measurement contract آن دیده شود: دقیقاً چه Source/Version/Rule/Scope/Baseline/Reportی تحلیل شده، Processing چه وضعی داشته، Gate چه Conditionsی داشته و Issueها چگونه Triage شده‌اند. Green را محدود تفسیر کنید، Upgrade را آزمایش کنید و هر تصمیم را به Evidence وصل کنید؛ نه به عدد یا Badge تنها.