11 KiB
11 KiB
Programming language recommendations
Azure DevOps Pipeline
The following programming languages are included in the comparison:
- C# (.NET)
- Shell Scripting Bash / Zsh
- Python
- JavaScript / TypeScript
- Ruby
- Go
- PowerShell
- Java
Comparsion of the most important points
Legend for simple scales used below
- Extensions: Limited, Moderate, Extensive
- Simplicity in YAML: Easy, Medium, Complex
- Installation of Dependencies: Easy, Moderate, Complex
- Execution Speed: High, Moderate, Low
- Readability: Easy, Moderate, Hard
| Feature | C# | Shell (Bash/Zsh) | Python | JavaScript / TypeScript | Ruby | Go | PowerShell | Java |
|---|---|---|---|---|---|---|---|---|
| 1. Data processing (PDF) | Extension needed (e. g., iTextSharp, PDFSharp) | External tool (e. g., Ghostscript) | Extension needed (e. g., PyPDF2, ReportLab) | Extension needed (e. g., pdf-lib, PDFKit) | Extension needed (e. g., Prawn) | Extension needed (e. g., go-pdf) | Extension needed (e. g., same .NET PDF libs invoked from PowerShell) | Extension needed (e. g., iText7, Apache PDFBox) |
| 2. Data processing (AsciiDoc) | Extension needed (e. g., Asciidoctor .NET wrappers) | External tool (e. g., Asciidoctor) | Extension needed (e. g., asciidoc-py3) | Extension needed (e. g., @asciidoctor/core) | Extension needed (e. g., Asciidoctor) | Extension needed (e. g., use CLI or wrappers for Asciidoctor) | External tool (Asciidoctor) or .NET-based wrappers | Extension needed (e. g., AsciidoctorJ) |
| 3. Data processing (JSON) | Built-in (System.Text.Json) | External tool (e. g., jq) | Built-in (json) | Built-in (JSON.parse, JSON.stringify; in Node, no extra install needed) |
Built-in (json) | Built-in (encoding/json) | Built-in (ConvertFrom-Json, ConvertTo-Json in modern PowerShell) |
Extension/library commonly used (e. g., Jackson, org.json) |
| 4. Data processing (YAML) | Extension needed (e. g., YamlDotNet) | External tool (e. g., yq) | Extension needed (e. g., PyYAML) | Extension needed (e. g., js-yaml) | Built-in (Psych) | Extension needed (e. g., gopkg.in/yaml.v3) | Built-in in newer PowerShell versions (ConvertFrom-Yaml, ConvertTo-Yaml) |
Extension needed (e. g., SnakeYAML) |
| 5. Data processing (XML) | Built-in (System.Xml) | External tool (e. g., xmlstarlet) | Built-in (xml) | Mostly extension (e. g., xml2js, fast-xml-parser) | Built-in (REXML, Nokogiri) | Built-in (encoding/xml) | Built-in (native [xml] type accelerator) |
Built-in (javax.xml, org.w3c.dom, plus standard libraries) |
| 6. Extensions (libraries / packages) | Extensive (NuGet) | Extensive (rich set of CLI tools, though not “extensions” in the same sense) | Extensive (PyPI) | Extensive (npm is one of the largest ecosystems) | Extensive (RubyGems) | Extensive (Go Modules) | Moderate (PowerShell Gallery) | Extensive (Maven Central, Gradle plugins) |
| 7. Simplicity in YAML usage | Medium (third-party library but straightforward) | Complex (usually rely on yq or custom scripts) | Easy (with PyYAML) | Medium (need js-yaml, usage is direct in Node/TS) | Easy (built-in Psych) | Medium (import 3rd-party package, usage is simple) | Easy (native cmdlets in newer versions) | Medium (SnakeYAML is straightforward, but an extra lib) |
| 8. Must be compiled? | Yes (C# -> .NET IL) | No (interpreted scripts) | No (interpreted) | JS: No (interpreted), TS: Yes (transpiles to JS) | No (interpreted) | Yes (compiled to native binaries) | No (interpreted on .NET runtime) | Yes (compiled to JVM bytecode) |
| 9. Cross-Platform | Yes (with .NET Core/.NET 5+) | Yes (native to Unix-like, plus Windows via WSL or separate install) | Yes (Windows, macOS, Linux) | Yes (Node.js or browser; TS runs where JS runs) | Yes (Windows, macOS, Linux) | Yes (Windows, macOS, Linux, others) | Yes (PowerShell Core 6+ is cross-platform) | Yes (JVM on Windows, macOS, Linux, etc.) |
| 10. Simple installation of dependencies | Moderate (NuGet + .NET CLI or Visual Studio) | Moderate (install packages/tools via apt, yum, brew, etc.) | Easy (pip, Conda, etc.) | Easy (npm, yarn, etc.) | Easy (RubyGems, Bundler) | Easy (Go modules, go get) | Moderate (PowerShell Gallery + extra config) | Moderate (Maven, Gradle; straightforward but verbose) |
| 11. Licensing | Open-source .NET (MIT for .NET Core); older .NET frameworks under MS licenses | GPL (GNU Bash) | PSF License (Python Software Foundation) | JavaScript is an ECMA standard; TypeScript is Apache 2.0 by Microsoft | Dual License (Ruby License/BSD) | BSD-style (Go is open source under a permissive license) | MIT License (for PowerShell Core; Windows PS is proprietary) | GPL v2 + Classpath (OpenJDK); Oracle JDK has different commercial terms |
| 12. Provider / Owner | Microsoft (language + runtime) | GNU Project (part of GNU utilities) | Python Software Foundation | ECMA standard for JS; Microsoft for TS | Yukihiro “Matz” Matsumoto / community | Google (initially) + open source community | Microsoft (PowerShell) | Oracle + open source community |
| 13. Execution speed | High (JIT on .NET, typically quite fast) | Low (relies on external tools; not optimized for heavy computation) | Moderate (interpreted, can be fast but slower than C#/Go/Java) | Moderate (Node’s V8 engine is JIT-compiled; usually slower than fully compiled languages) | Moderate (CRuby slower; newer versions have partial JIT) | High (compiled to native) | Moderate (.NET-based, typically good performance but overhead in interactive scenarios) | High (JIT-compiled by the JVM; often on par with C#) |
| 14. Code comprehension & readability | Moderate (C-style syntax, can be verbose) | Hard (complex quoting, expansions, and nuances in Bash) | Easy (clean, minimal boilerplate) | Moderate (JS can be flexible/loose; TS adds structure but extra overhead) | Easy (expressive, some “magic” features) | Easy (simple, explicit, fewer features) | Moderate (familiar C#-like syntax + cmdlet conventions) | Moderate (verbose, strongly typed, boilerplate-heavy) |
| 15. Certification available (employee) | Yes (Microsoft .NET/C# certs) | Indirect (part of broader Linux certifications like LPIC, RHCSA) | Yes (e. g., PCAP) | No official (some vendor-specific or full-stack certs may include JS/TS) | No official (third-party training only) | No official (no widely recognized Go cert; some third-party) | Yes (covered in broader MS certs, though not strictly “PowerShell-only”) | Yes (Oracle Certified Professional Java Programmer, etc.) |
| 16. Debugging capabilities | Strong (Visual Studio, VS Code with C# extension) | Limited (VS Code has bash-debug, but fewer features) | Strong (VS Code, PyCharm, pdb, etc.) | Strong (VS Code debugger for JS/TS, Chrome DevTools, Node Debugger) | Moderate (VS Code Ruby extensions, RubyMine) | Strong (VS Code Go extension + Delve) | Strong (VS Code PowerShell extension with integrated debugger) | Strong (VS Code Java extension, IntelliJ, Eclipse) |
| 17. Testing framework | Yes (NUnit, xUnit, MSTest) | Yes (e. g., shUnit2, Bats) | Yes (unittest, pytest, nose, etc.) | Yes (Jest, Mocha, Jasmine, etc. for JS; Mocha/Jest + ts-node for TS) | Yes (RSpec, Minitest) | Yes (testing in stdlib) | Yes (Pester for PowerShell) | Yes (JUnit, TestNG, etc.) |
Recommended Language: Python
Python has most features or the best value on scale. The most benefits compared to the other languages:
- Data Handling: pull data, parse it, and then format it.
- Document Generation: The libraries for data presentation are fast and simple.
- Dependencies: are easy handled with requirments.txt.
- Virtual Environments: allows different Python versions to be used in the same pipeline.
- REST APIs: can be simple used with the Pythons requests library.
Example Workflows for Python
Install Dependencies
Use a pipeline task to install Python (if not already on the agent) and the required libraries.
- task: UsePythonVersion@0
inputs:
versionSpec: '3.x'
- script: |
pip install requests python-docx reportlab jinja2
Fetch Work Items
Write a Python script to call the Azure DevOps REST API to retrieve Work Items.
import requests
# Example: Get Work Items from Azure DevOps
devops_organization_url = "https://dev.azure.com/YOUR_ORG"
project = "YOUR_PROJECT"
api_version = "6.0"
query_id = "YOUR_QUERY_ID"
response = requests.get(
f"{devops_organization_url}/{project}/_apis/wit/wiql/{query_id}?api-version={api_version}",
auth=('PAT_USERNAME', 'PAT_TOKEN') # or use other Auth methods
)
work_items_data = response.json()
Generate Compliance Documents
Convert the retrieved data into the document format of your choice.
from docx import Document
from docx.shared import Inches
document = Document()
document.add_heading('Compliance Report', level=1)
for item in work_items_data["workItems"]:
document.add_heading(f'Work Item ID: {item["id"]}', level=2)
# Additional data insertion here...
document.save('ComplianceReport.docx')