0

I am working on a java (maven) project where the code on dev/testing environments is different than the production one. The different parts are mainly configuration files or files related to Docker, but still, this creates a lot of confusion. If I were to keep the pom file or the Dockerfile of prod, dev wouldn’t work and vice versa.

Right now, when deploying to prod, I create a new branch in git from an existing deploy branch that has already the different Dockerfile and pom.

There, I checkout the changes from the src/ directory like

$ git checkout origin/feature-name —- src/

and manually provide any other changes if necessary to the rest of the files.

All this process turns to be tedious with many possible errors around the corner (if let’s say I forget to change a version of a dependency). Furthermore, this stops me from automating the deployments to production. How can I work around this situation?

UPDATE

The actual code in the src/ directory is not changing. The changes between environments are

  • dev/test environments are using secrets, but prod doesn't, meaning different docker-compose files and different entrypoint
  • The pom file in production has additional elements (i.e. a parent pointing to a private artifact). As mentioned by @Saeed, using profiles cannot add/change or elements.
  • The Dockerfile in production is using private images not accessible during development (or testing) I am using a public equivalent instead.
kostia
  • 324
  • 5
  • 18
  • 1
    If your testing and production code bases are different, how do you actually test the code you're shipping to production? I'd try to fix that first; you'll naturally have different configurations (replica counts, database setups, hostnames) but the actual _code_ should be the same. In a Docker context, you should be running the same single image in all environments. – David Maze Feb 02 '20 at 00:41
  • I have updated the question with a set of differences between the environments. I hope that helps – kostia Feb 03 '20 at 07:41

1 Answers1

0

I think Maven profiles is a good choice to create your customized build configurations, like targeting a level of test granularity or a specific deployment environment.

according to Maven documentation a profile can customize following elements of POM

<repositories>
<pluginRepositories>
<dependencies>
<plugins>
<properties> (not actually available in the main POM, but used behind the scenes)
<modules>
<reporting>
<dependencyManagement>
<distributionManagement>

a subset of the <build> element, which consists of:

<defaultGoal>
<resources>
<testResources>
<finalName>

you can have completely different set of setting files and even dependencies, plugins and etc for different environments and purposes

for example in a profile you can configure it to skip the tests:

<profile>
    <id>no-tests</id>
    <properties>
        <maven.test.skip>true</maven.test.skip>
    </properties>
</profile>

and when you pass profile name to Maven and activate it by -P switch , Maven will apply customization defined inside a profile and in this example by running:

mvn clean install -P no-tests

it will skip running tests

Maven profiles are really powerful and handle highly customization if you can utilize it well

Saeed Alizadeh
  • 1,417
  • 13
  • 23
  • thank you so much for your extended answer. That was my first idea but unfortunately besides the , and that I can change, there are other elements that I cannot. These are specific for the production environment i.e. and that are pointing to information available only within the production. This is not possible (as stated here https://stackoverflow.com/questions/6507019/maven-selecting-parent-project-based-on-profile as well). I wish I could use another solution than keeping two separate files. – kostia Feb 03 '20 at 07:26
  • 1
    about scm in other stackoverflow question a solution provided https://stackoverflow.com/questions/37893346/different-scm-for-different-profiles-in-maven – Saeed Alizadeh Feb 03 '20 at 10:17
  • and also about multi parent project you can check here https://stackoverflow.com/questions/1636801/can-maven-projects-have-multiple-parents combination all of these might solve your problem – Saeed Alizadeh Feb 03 '20 at 10:49
  • The solution for scm seems promising, but the parent still remains. This because the new parent is a private artifact that is not accessible during development and this creates errors. – kostia Feb 03 '20 at 12:14