Xây dựng quản lý cấu hình trong Android/Intellij/Jenkins

Question

Câu hỏi này có thể chủ quan, nhưng tôi cho rằng Stackoverflow vẫn là nơi tốt nhất để hỏi:

Miền vấn đề là "lập trình Android nâng cao". Tôi không cần thông tin về cách thiết lập một dự án Android đơn lẻ, cách sử dụng các dự án thư viện hoặc cách sử dụng ANT để xây dựng một dự án bình thường.

Giả sử bạn có một ứng dụng đang chạy, một dự án Android thông thường (IDE của sự lựa chọn là IntelliJ, nhưng điều đó không thực sự quan trọng) được xây dựng bởi Jenkins/Ant/Proguard. Kết quả của bản dựng này là APK cuối cùng bạn sẽ đặt trong cửa hàng Play.

Bây giờ hãy tưởng tượng bạn cần ứng dụng này dưới dạng phiên bản miễn phí và trả phí. Không có vấn đề gì cho đến nay, chỉ cần đặt tất cả mã được chia sẻ vào một dự án thư viện và tạo hai dự án con, một dự án có kiểm tra giấy phép bật App.java, ví dụ khác, ví dụ: hạn chế việc sử dụng.

Bây giờ hãy tưởng tượng bạn muốn nhắm mục tiêu Amazon, có thể có phiên bản thông cáo báo chí, v.v. Vì vậy, mã của bạn bắt đầu phân kỳ, vẫn còn nhiều thứ được chia sẻ, nhưng một số phần cụ thể cho ví dụ. thị trường bạn nhắm mục tiêu.

Trong C# có "câu lệnh biên dịch có điều kiện", như "IF PLAY_STORE ...". Có điều gì tương tự cho Java/Android không. Ngoài ra, họ có chơi tốt với ANT và quá trình xây dựng không.

Nhưng tôi không giới hạn trong việc biên dịch có điều kiện. Phương pháp "một dự án trên mỗi thị trường" là một phương pháp khác. Tôi chỉ cố gắng để có được một cảm giác về cách bạn quản lý các "cấu hình xây dựng" khác nhau theo cách bền vững. Có nghĩa là nó hoạt động cho 15 dự án, nhắm mục tiêu 3 thị trường trong 2 hương vị (MIỄN PHÍ và TRẢ TIỀN). Tôi hy vọng bạn thấy những gì tôi đang ám chỉ. Mã này rất giống với tất cả các ứng dụng, nhưng với ví dụ ở trên, tôi sẽ có 90 APK khác nhau - với những con số này, "bình luận thủ công trong mã nguồn chỉ cần bởi bản dựng này, v.v." không cắt nó nữa. Vì vậy, mọi mẹo, công cụ, từ tìm kiếm, trải nghiệm với miền có vấn đề này (ví dụ: MAVEN, nó có giúp ích gì cho tôi hay không, hoặc là ANT + scripts tạo tệp build.xml tốt hơn). Một ví dụ khác, nếu tôi có một dự án Android "thực" cho tất cả các thị trường mục tiêu, điều này sẽ cho phép tôi làm hầu hết mọi thứ. Nhưng tất nhiên, mặt khác, nếu tôi thêm một trang mới ở mức thấp nhất (ví dụ như một trang chi nhánh nhà xuất bản), tôi sẽ cần phải đi vào 90 Manifest.xml để thêm trang ...

Cảm ơn bạn đã trợ giúp này, Chris

PS: tôi sẽ bổ sung thêm một số liên kết tôi tìm thấy liên quan đến chủ đề này tại phía dưới, nếu ai đi qua câu hỏi này trong khi không có câu trả lời, điều này có thể là một "đầu tiên đọc" phần

http://www.asyncdev.net/2011/02/android-dev-prod-builds/

http://www.slf4j.org/ (liên quan đến "đặt JAR trong t o cung cấp IMPL "cách"

(SLF4J chỉ là một cách tiếp cận tốt đẹp để giảm phụ thuộc và cung cấp cấu hình trong quá trình triển khai - chỉ cần thêm một JAR khác. Để sử dụng một cái gì đó như thế này có thể là quá mức cần thiết cho các dự án của riêng bạn, nhưng nó sẽ là một cách. Ví dụ. cho giao diện ghi giấy phép và một chút mã như SLF4J, sau đó cung cấp hoặc PressRelease.jar hoặc Productive.jar trong thư mục Lib trong khi xây dựng, thay đổi cách ứng dụng hoạt động ...)

Answer 1

Câu hỏi này có phần ý kiến ​​dựa vào trong một dự án phức tạp luôn có hơn 1 giải pháp phù hợp.

Preamble

tôi sẽ cố gắng giải thích một số nguyên tắc tôi đã sử dụng để triển khai Linderdaum Puzzle HD. Trò chơi đã trả tiền và các phiên bản miễn phí khác với mã, nhưng trong giao diện người dùng và nội dung trò chơi.

Trò chơi được phát hành cho hai nền tảng và một số cửa hàng (mà tất cả đều có cơ chế ủy quyền khác nhau):

Android:

1. Google Play (2: miễn phí + trả tiền)
2. AndroidPit (2 : miễn phí + trả tiền)
3. SlideMe (1: miễn phí)
4. Samsung cửa hàng (1: miễn phí)

Blackberry OS 10

1. BlackBerry World (1: trả)

của Windows

1. Chúng tôi sử dụng phiên bản này để phát triển và thử nghiệm trên một máy tính (1: thanh toán)

Điều này cung cấp cho chúng tôi 8 khác nhau distri gói bution.

Môi trường

toolchain sản xuất của chúng tôi dựa trên git và TeamCity. Không có công cụ đặc biệt nào (như Maven, Gradle) được sử dụng.

Giải pháp

Sự kết thúc điểm của quy trình làm việc của chúng tôi là trang dự án TeamCity nơi chúng tôi có tất cả xây dựng cấu hình tương ứng với 8 gói phân phối cộng với một số khác được xây dựng để gỡ lỗi (ví dụ: với kiểm tra bổ sung và các bản ghi). Bất kỳ gói nào cũng có thể được xây dựng thông qua giao diện web từ bất kỳ đâu trong một lần nhấp.

Đối với mỗi gói có tên chi nhánh git (được chia sẻ bởi một số gói) để TeamCity biết được nơi lấy nguồn. Hiện tại chúng tôi có các chi nhánh này:

remotes/origin/master 
    remotes/origin/release300-blackberry 
    remotes/origin/release300-master 
    remotes/origin/release300-paid_apps 
    remotes/origin/release300-paid_apps_androidpit 

Ở đây release300 đại diện cho phiên bản của trò chơi. Chúng tôi có nhiều chi nhánh lưu trữ cho chúng. Đây không phải là các chi nhánh phát triển hoặc tính năng - chúng chỉ sử dụng để giữ các thay đổi cho gói trò chơi cụ thể. I E. trong số paid_apps có nhiều nội dung trò chơi hơn và paid_apps_androidpit chứa thư viện cấp phép AndroidPit.

Sự phát triển diễn ra trong master và trong các chi nhánh tính năng được hợp nhất trở lại làm chủ. Sau đó, một quá trình hợp nhất diễn ra.Hướng sáp nhập là (và chỉ những hướng dẫn):

master -> release300-master -> release300-paid_apps -> release300-paid_apps_androidpit 
     \ 
     \-> release300-blackberry 

tức là, release300-paid_apps_androidpit đã cơ bản cùng một nội dung như release300-paid_apps, tuy nhiên, nó bổ sung thêm một số tính năng mới (như việc cấp phép thư viện, vv). Và release300-blackberry hoàn toàn tách biệt vì nó phải nhắm mục tiêu các thiết bị có tỷ lệ màn hình bất thường 1: 1 và có giao diện người dùng thiết kế đặc biệt. Vì vậy, 5 chi nhánh này được sử dụng để xây dựng 8 gói distro của chúng tôi.

Chúng tôi không bao giờ hợp nhất các thay đổi từ các nhánh phát hành này trở lại thành thạo. Các sửa lỗi được truyền theo cùng một hướng.

Mỗi gói có tệp tập lệnh riêng, I.e. xây dựng ứng dụng miễn phí cho Google Play cũng đơn giản như gọi tập lệnh Python BuildAndroid.py trên chi nhánh release300-master.

Ý tưởng tương tự cũng áp dụng cho tất cả các gói khác: chỉ sử dụng một dòng lệnh dòng lệnh TeamCity của TeamCity.

Answer 2

Bạn chắc chắn nên có một cái nhìn tại

1. dự án Thư viện - điều này sẽ giúp bạn với tách mã đúng và chơi tốt với ant - hãy nhìn vào bài thuyết trình của chúng tôi tại droidcon đây: http://skillsmatter.com/podcast/agile-testing/building-your-app-for-multiple-app-stores)
2. Gradle (còn gọi là "hệ thống xây dựng mới") - điều này sẽ giúp bạn xây dựng các điều kiện dễ dàng hơn và tích hợp IDE tốt hơn một chút (với Android Studio) mới xem thêm thông tin tại đây: http://tools.android.com/tech-docs/new-build-system)

UPD: Như tôi thấy, bạn đã sử dụng LP cho các dự án của bạn. Một số lời khuyên cho quá trình ra này dễ dàng hơn:

1. Sử dụng manifestmerger.enabled=true

2. Hãy xem github.com/onepf/OpenIAB

Answer 3

Nếu bạn đang mắc kẹt với ant vì những lý do bạn không thể kiểm soát, xem xét sử dụng bộ lọc và mã thông báo. Bạn có thể có .java tệp được tạo từ các mẫu tương ứng với cấu hình hoặc logic nghiệp vụ cho từng loại. Dưới đây là một ví dụ chính thức:

<copy file="${build.dir}/version.txt" toFile="${dist.dir}/version.txt"> 
    <filterset begintoken="%" endtoken="*"> 
    <filter token="DATE" value="${TODAY}"/> 
    </filterset> 
</copy> 

này sẽ thay thế các văn bản @DATE* trong ${build.dir}/version.txt với ngày hiện tại và sao chép kết quả để ${dist.dir}/version.txt. Điều này, cùng với một số nhánh thông minh, có thể cung cấp cho bạn một bộ tiền xử lý nửa phong nha. Nhược điểm là, tất nhiên, rằng nó thực sự chậm (ant nói chung là, điều này thậm chí nhiều hơn như vậy).

Tôi thực sự muốn giới thiệu Gradle, vì nó có chức năng này được xây dựng (hương vị sản phẩm) nhưng tiếc là đó không phải là một lựa chọn nghiêm trọng trong khi đang phát triển tích cực. Có lẽ trong một vài tháng nhưng không phải bây giờ.