Software Development Environments

I’ve written in the past about Software Development Environments https://tomavelev.com/blog/Software%20Environments. Their ultimate goal is to have the same source code – running everywhere – with just – settings/data difference. In short, they are:

• Local/Dev
• Test
• Integration
• Staging
• Production

This time I’m gonna point out some examples in Flutter and Java. 

Flutter flavours

Flutter projects does not generate flavoured code out of the box, but offers CLI arguments. Thanks to the Open Source contributions like rx_blic_cli, There are code generators and project bootstrappers that give you multi-dimensional environment setup out of the box. There are even run configurations for the IDE.

• These settings are build with the help of flutter flavors, the command line argument  flutter run --flavor. Basically – you could define different main.dart file – for each environment.
• Also, you could have different environment variables, especially useful during development and testing. 

All the above is taking advantage of the environmental settings from Android or configuration targets for iOS.

Java Environments through Properties

In Java, you can archive different environments through properties files. A properties file is a plain text file that contains key-value pairs that can be used to configure an application. Here’s how you can do it:

1. Create a properties file for each environment you want to archive and default- file that will be read by the app. For example, you might create a file named “development-db.properties” for your development environment, and a file named “production-db.properties” for your production environment.

2. Define the key-value pairs in each properties file. The keys should be descriptive names for the configuration values, and the values should be the specific configuration settings for that environment. For example, in your “db.properties” file, you might define a key called “database.url” with a value of “jdbc:mysql://localhost:3306/dev_db”.

3. Load the properties file for the current environment at runtime. You can do this by using the Properties class in Java, which provides methods for loading properties files. For example, you might use the following code to load the properties file for the development environment:

Properties props = new Properties();
props.load(new FileInputStream("db.properties"));

4. Retrieve the configuration values from the properties object. You can use the getProperty method of the Properties class to retrieve the values of specific keys. For example, you might use the following code to retrieve the value of the “database.url” key:

Here you could read a tutorial from a older than this blog – about the topic. You can archive different environments through profiles. A profile is a named set of configuration options that can be used to customize the behavior of your application for different environments. 

1. Define the profiles you want to use in your application. You can define profiles in your application.properties or application.yml file. 

spring:
profiles:
active: development
---
spring:
profiles: production

2. Define the configuration options for each profile. You can use the same properties or YAML syntax to define configuration options for each profile. For example, you might define a database URL for each profile like this:

spring:
datasource:
url: jdbc:mysql://localhost:3306/dev_db
---
spring:
datasource:
url: jdbc:mysql://prod-db.example.com:3306/prod_db

Use the configuration options in your application. Spring Boot will automatically load the configuration options for the active profile. You can use the @Value annotation to inject configuration values into your code.

@Component
public class MyComponent {

@Value("${spring.datasource.url}")
private String dbUrl;

// Use the dbUrl variable in your code
}

Activate a profile at runtime. You can activate a profile at runtime by setting the “spring.profiles.active” property.

java -jar myapp.jar --spring.profiles.active=production

By using profiles to archive different environments, you can easily switch between configurations for different environments without having to modify your code. Once all these settings are part of CI/CD – it can save you time and reduce the risk of errors when deploying your application.