Posted by Andrew Phillips mid-afternoon: July 5th, 2010
Sometime in the bright future, you will be able to deploy the same virtual appliance containing your application to all your target environments without adjustments. For the time being, however, deployments to traditional DTAP1 landscapes almost always mean “tweaking” the application and associated configuration and resources to match the target environment – think endpoints, properties files or datasource usernames and passwords, to name but a few.
In the absence of any established standards or even guidelines in this area, many different solutions to this problem of deployment package customization have been employed, from fairly elegant approaches such as JMX to crude string search-and-replace.
Furthermore, different types of middleware platforms have varying degrees of support for customizations: typically, portals, ESBs and process servers offer some “native” solution to the problem, whereas application servers tend to leave users to fend for themselves.
More often than not, the result is a chaotic mix of customization approaches across projects, target platforms and departments2. Here, we’ll look at some of these approaches, classify them and examine some drawbacks and benefits. (more…)
Posted by Sander Hautvast mid-afternoon: June 4th, 2010
In this episode of the middleware pitfalls top-10 we want to discuss the merits of a clean and standardized set of (test) environments. Some refer to such a set as DTAP, an acronym for Development, Test, Acceptance-test (or pre-production) and Production. From here on the text contains capitals to indicate an environment. Basically the situation is like testing itself: you will never get it 100% right, but it will help you a lot if you invest in a sound, maintainable DTAP.