Believe me, it happens more than we think. Boom! The data is in production and your product has a little problem. One day a developer decides to play with this database, add ‘test’ data and forget to remove it. Also, a member of the team who doesn't have permissions can't change variables for release deploy - of course, if the team creates a secure CI environment.įor example, imagine your app needs to pre-populate a SQLite database and the file is on your root project. In this case, developers don't need to concern about these definitions. #3 Keys public static final String API_KEY = "2FA43FADFaw432dfa"Īll of these constants above could be defined as build variables. #2 File paths or filenames public static final String DB_FILEPATH = "common/path/db.sqlite" #1 Base URLs (hostnames) public static final String API_BASE_URL = "" For every build type such as development, staging, release (I'll write something about build types) we can create specific configuration or a group of variables. Here is the most important part of setting a great environment with consistent variables. Developers develop, Gradle builds and users consume app :) Build variables for build variants
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |