Release Packaging & Dependency Management

[dangquangminh]

Release Packaging & Dependency Management – Vì sao ứng dụng chạy trên máy Dev nhưng lại lỗi trên Production?


Một trong những câu nói quen thuộc nhất trong ngành phần mềm là:

"Code chạy trên máy tôi mà!"

Câu nói này thường xuất phát từ việc quản lý package và dependency không chặt chẽ. Khi ứng dụng phát triển ngày càng lớn, số lượng thư viện phụ thuộc (dependencies) tăng lên nhanh chóng, việc đóng gói (packaging), quản lý phiên bản (versioning) và kiểm soát môi trường thực thi trở thành những vấn đề sống còn đối với DevOps và Platform Engineering.

Một ứng dụng không chỉ là source code


Khi phát triển một ứng dụng, chúng ta không chỉ quản lý source code mà còn phải quản lý:

• Project files
• Modules
• Resource files
• Runtime Environment
• Dependencies
• Phiên bản của Interpreter hoặc Runtime

Ví dụ với Python, việc lựa chọn Python 2 hay Python 3 đã tạo ra hai môi trường hoàn toàn khác nhau vì chúng không tương thích với nhau. Thậm chí các thư viện cũng có thể yêu cầu những phiên bản Python khác nhau.

Một package hoàn chỉnh thường phải bao gồm:

• Version
• Changelog
• Documentation
• Dependency Description

Điều này giúp người dùng hoặc hệ thống triển khai biết chính xác phiên bản nào đang được sử dụng, các tính năng mới, bug fix và các yêu cầu về môi trường chạy.

Dependency Hell – Cơn ác mộng của mọi Developer


Giả sử:

Ứng dụng A yêu cầu:
requests==2.22.0

Trong khi ứng dụng B yêu cầu:
requests==2.31.0

Nếu hai ứng dụng cùng cài trên một máy và sử dụng chung môi trường Python, rất dễ xảy ra xung đột phiên bản.

Đây chính là thứ mà cộng đồng thường gọi là:

Dependency Hell.

Tình trạng này không chỉ xảy ra với Python mà còn xuất hiện ở:

• Node.js (npm)
• Java (Maven, Gradle)
• Go Modules
• Linux Package Managers
• Container Images

Package Manager – Người quản gia của hệ thống


Hầu hết hệ điều hành đều có Package Manager riêng:

• YUM
• DNF
• APT

Trong hệ sinh thái Python, công cụ phổ biến nhất là:
pip install requests

Pip sẽ tự động tìm package trong PyPI (Python Package Index), tải về và cài đặt toàn bộ dependencies cần thiết.

PyPI có lợi thế rất lớn:

• Đa nền tảng
• Không phụ thuộc Linux Distribution
• Dễ tích hợp CI/CD
• Dễ phân phối ứng dụng cho Windows, Linux, macOS

Trong khi đó, repository của hệ điều hành thường bị phân mảnh giữa các bản phân phối Linux khác nhau.

Setup.py – Khởi đầu của việc đóng gói Python


Python sử dụng thư viện:
setuptools

để xây dựng package.

Một file tối thiểu:
setup(
name="myapp",
version="1.0.0"
)

Tuy nhiên trong thực tế, Setup.py thường khai báo:

• Name
• Version
• Description
• Author
• License
• Required Packages
• Python Version
• Included Packages
• Excluded Packages

Đây là nền tảng của quá trình đóng gói và phát hành phần mềm trong hệ sinh thái Python.

Source Distribution và Wheel


Python hỗ trợ hai hình thức phân phối:

Source Distribution (sdist)


Phân phối mã nguồn.

Máy đích phải thực hiện quá trình build.

Thường không được khuyến nghị trong môi trường Production.

Wheel (.whl)


Định dạng nhị phân được build sẵn.

Ưu điểm:

• Triển khai nhanh
• Ít lỗi hơn
• Phù hợp Production
• Hạn chế phụ thuộc vào môi trường build

requirements.txt – Hợp đồng giữa Developer và Production


Lệnh:
pip freeze

sẽ xuất ra:
certifi==2026.x
idna==3.x
requests==2.22.0

Thông thường kết quả được lưu trong:
requirements.txt



Một số tổ chức khóa cứng:
requests==2.22.0

Trong khi nhiều tổ chức lại chọn:
requests>=2.22.0

để cho phép sử dụng các phiên bản mới hơn nhưng vẫn đảm bảo tương thích tối thiểu.

Việc cài đặt dependency chỉ còn:
pip install -r requirements.txt

Virtual Environment – Mỗi ứng dụng một thế giới riêng


Để giải quyết Dependency Hell, Python hỗ trợ:

Virtual Environment

Mỗi ứng dụng có:

• Python Interpreter riêng
• Bộ thư viện riêng
• Version riêng
• Không ảnh hưởng tới hệ thống hoặc ứng dụng khác

Ví dụ:
Application A
└── Python 3.10
└── requests 2.22

Application B
└── Python 3.13
└── requests 2.31

Hai ứng dụng có thể cùng tồn tại mà không xảy ra xung đột.

Pipenv – Quản lý Dependency hiện đại hơn


Pipenv hoạt động trên:

• pip
• Virtual Environment

Pipenv sử dụng: Pipfile


Khai báo yêu cầu tối thiểu. Pipfile.lock


Lưu toàn bộ dependency tree với phiên bản chính xác.

Điều này giúp:

• Reproducible Build
• Dễ triển khai CI/CD
• Giảm lỗi "Works on my machine"

Container – Lời giải tốt nhất cho Production


Tài liệu đánh giá rằng trong các giải pháp cô lập dependency:

• Virtual Environment
• Vagrant
• Containers

thì Containerized Environment là lựa chọn phù hợp nhất cho Production.

Lý do:

Container đóng gói:

• Application
• Runtime
• Libraries
• Dependencies
• Configuration

thành một đơn vị triển khai hoàn chỉnh.

Chỉ cần máy đích có:

• Docker
• Podman
• Kubernetes

là ứng dụng có thể chạy giống hệt môi trường Development.

Đặc biệt, Container không cập nhật "in-place". Khi có phiên bản mới, chúng ta chỉ cần phát hành một Image mới trong CI/CD Pipeline. Image cũ vẫn được giữ lại, giúp rollback cực kỳ đơn giản và an toàn.

Kết luận


Release Packaging và Dependency Management là một trong những nền tảng quan trọng nhất của DevOps hiện đại. Phần lớn các sự cố "ứng dụng chạy được trên máy Dev nhưng lỗi trên Production" đều bắt nguồn từ việc kiểm soát dependency không tốt.

Từ requirements.txt, pip freeze, virtualenv, Pipenv cho đến Docker Container, tất cả đều nhằm giải quyết một bài toán duy nhất:

Làm thế nào để môi trường thực thi của ứng dụng có thể được tái tạo chính xác ở mọi nơi.

Đây cũng chính là lý do Container và Infrastructure as Code đang trở thành tiêu chuẩn trong các hệ thống Cloud Native và Platform Engineering ngày nay.

devops #PlatformEngineering python #DependencyManagement #Packaging #Docker container #CloudNative automation #InfrastructureAsCode #SecDevOps