• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Ron McLeod
  • Liutauras Vilda
  • Paul Clapham
  • paul wheaton
Sheriffs:
  • Tim Cooke
  • Devaka Cooray
  • Rob Spoor
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Tim Moores
  • Carey Brown
  • Mikalai Zaikin
Bartenders:

Build & Deploy for different environment

 
Greenhorn
Posts: 5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Not sure if this is the best forum to this question, but it's build & deployment related question...

When you deploy to production, do you build for two environments using different properties files and deploy both?
Or do you simple sync the files from production to offsite then change the configuration files?
Any input or is there any best practice on this?

Thanks in advance!


 
author
Posts: 3285
13
Mac OS X Eclipse IDE Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
It's generally considered best practice to have separate configuration files per environment or to have filterable configuration files, e.g. Have ${} replacement in Maven or @@ replacement in Ant). Typically you would build your artifact (jar/whatever) and then run an environmentalisation phase/target.

e.g. ant -Denv=production update_configuration_files

That way your environment free code (JAR/classes) remains separate from your code that you need to environmentalise.

Hope that made sense!
 
author
Posts: 5856
7
Android Eclipse IDE Ubuntu
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Martijn's recommendation is right-on if you own the production site and/or you know the site's configuration settings.

A slight variation can be done in the event that you don't know the final site's configuration, such as, for example, you have many customers to which you ship your app. In that case, one thing you can do is place all site-specific configuration information into a single properties file. Then have the customer change the properties to match his site, and then provide an script which is run to install/deploy the app and update the configuration files. You can always hide the ant call behind a shell script named 'install'. You could even forgo the properties file and have the ant script query the user about the information. I use this mechanism often at work when I want to pre-packge one of my apps for my colleagues but have no idea what their system might look like (it might not even be set up yet!).

I hope that makes sense and that it helps.
 
Saloon Keeper
Posts: 27478
195
Android Eclipse IDE Tomcat Server Redhat Java Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Actually, I prefer to build ONE unit for all environments and control the details by injecting configuration information. You can do this easily using JNDI and the Context xml configuration in Tomcat for simple stuff, or keep more complex infomation in an external file or database and inject the location of that information.

The advantages of this are that I don't have to juggle 2 different types of builds and if something goes wrong in production, I don''t have to worry about build differences on the test system hiding the problems with the production code.
 
Blueberry pie is best when it is firm and you can hold in your hand. Smell it. And smell this tiny ad:
a bit of art, as a gift, that will fit in a stocking
https://gardener-gift.com
reply
    Bookmark Topic Watch Topic
  • New Topic