Postgresql Hot Standby for Windows

To get started you need two machines that are the same architecture, ie 64 bit, with the same version of Postgres installed, including same Postgres architecture.

1. On Master – In pgAdmin run:


2. On Master – In pgAdmin, edit the postgresql.conf and set the following:

wal_level = hot_standby

max_wal_senders = 3

checkpoint_segments = 8

wal_keep_segments = 8

3. On Master – In pgAdmin, edit the pg_hba.conf and set the following where is the ip address of the slave:

host replication     replicator           trust

4. On Master – restart the postgres windows service

5. On Slave – stop the postgres windows service

6. On Slave – open a command prompt and cd to your Postgres directory (c:\program files\Postgresql\9.4) and run:

rd /s “c:\program files\Postgresql\9.4\data”

7. On Slave – open a command prompt and cd to your Postgres directory (c:\program files\Postgresql\9.4) and run where is the ip of the Master:

pg_basebackup -h -D “c:\program files\Postgresql\9.4\data” -U replicator -v –P –X stream

8. On slave – In pgAdmin, edit the postgresql.conf and set the following:

hot_standby = on

9. On slave – create a text file (c:\program files\Postgresql\9.4\data\recovery.conf) with the following contents where is the ip of the Master:

standby_mode = 'on'primary_conninfo = 'host= port=5432 user=replicator password=mypassword'trigger_file = 'c:\temp\postgresql.trigger'

10. On Slave – start the postgres windows service

Master and Slave should now be in sync. Update Master DB and confirm that the Slave is updated as well.

Release Packaging

Just as Applications package together components. Releases package together Applications.  This packaging enables you to release multiple applications together out to an environment.  Applications dependencies are at a higher level than component to component dependencies.  These dependencies are usually driven by changes in data structures, communication layers or by reusable components.

Everyone get up and move over…

Lets say that you have a reusable logging routine that has changed (backward compatibility broken) and multiple applications consume the reusable logging routine from a shared area.  Each application should be re-released using the new logging routine.  Release packaging in Release Engineer enables you to create a release with all of the applications that use the reusable logging component and then deploy the whole release to an environment, instead of deploying each application individually.  Also, the release packaging shows at a quick glance which applications are going to be deployed.  Everything is transparent so applications are not missed.

Application Packaging

We have defined that components are made up of runnable binaries.  And that components can depend upon each other.  Applications depend upon components as well.  You can think of components being the building blocks to making an application.  It is a matter of packaging the right components together to make an application run and function.  This packaging can include not only binary components, exes and dlls but also database components (table changes, indexes etc).

When you create an Application in Release Engineer, you are defining everything that that application needs to run, binaries, config files, properties, and database components.  We then can deploy the application which in turn deploys all of the components that the application consumes.  Release Engineer then drills down into the components and sends those binaries and database changes to the right servers.

Also, in Release Engineer you can have applications that need to released at the same time, but thats topic is for another post.

Release Engineer now includes a built-in command line interrupter

In our latest version of Release Engineer, we have included a built-in command line interpreter. This allows you to write portable, or platform independent, deployment flows. For example, your WebSphere deployment logic for a Windows Server can now be used for a Linux machine. No need to re-write the script that executes the detail logic of your deployment. This new feature is available via our download site at

What is a component?

I view components as a set of binaries, .exes and .dlls or ,jars that make up a runnable part of an application.  Components can consume other components.  For example, the date time component can consume the logging component.

A well architected component will avoid circular component dependencies, even if the dependencies are removed by several layers.  Circular component dependencies will cause headaches in the build and in the deployment process.  Make a new component if you run into circular dependencies that way it can be reused correctly.  You want see a component hierarchy that has all the relationships going in one direction.

64 bit Release Engineer

100% 64 bit Release Engineer is now available from

This version requires a 64 bit Windows machine, Java 1.7 64 bit or Java 1.8 64 bit, Postgresql Database 64 bit and Postgresql ODBC Driver 64 bit.

Deployments to 32 bit Windows Servers, 32 bit Linux/Unix are still available since Release Engineer is agent-less.

Free CA Harvest User Conference

In case you are not following the Harvest Community – I wanted to make you aware that registration is now OPEN for our CA AppDev Technical Conference.

This is a FREE Technical Seminar that will feature many of the CA AppDev products including CA Harvest SCM with Meister setup as a CI Server. Seating IS limited to please be sure to submit your registration form ASAP.

Registration information (including session agendas and recommended Hotels) can be found at the community:

Hope to see you in May!

Forrester Research Shares Agile Requirements and Testing Best Practice for Regulated Industries

Forrester’s Principal Analyst and Vice President, Diego Lo Giudice, recently collaborated with one of our key technology partners, Polarion on an exceptionally well received webinar titled “Agile Requirements And Testing For Continuous Software Delivery” .

In his presentation, Diego shared valuable information on modern application delivery trends and how they can be applied to the complex development challenges in regulated industries. He set the stage by stipulating that compliance and complexity represent a hurdle, but not a barrier, to successful agile development practices, and that such practices are becoming mission critical to enable innovation at ever accelerating speed across the board.

In fact, 2014 Forrester survey results shared by Diego substantiate that Agile methodology adoption is growing across engineering organizations worldwide, with 41.7% of 637 global software developers indicating that it is the “methodology that most closely reflects the development processes currently in use.”

Furthermore, according to the findings, DevOps or Agile all the way through is growing, resulting in the following top three benefits:
• One lifecycle and streamlined process, where everyone is involved in releasing business value
• Shared goals, where operations and development connected on business goals
• Tooling that integrates, representing huge opportunities for process automation.
You can learn all about Diego’s recommendations from the Polarion site 


Continuous Delivery Vs. ARA

Continuous Delivery (CD) is a process, not a solution. Continuous Delivery is an extension of  Continuous Integration. When a software update is saved to the version repository, the Continuous Integration workflow is triggered to execute steps that may include the calling of a script to compile code into binaries (Continuous Build), followed by a script to deliver the binaries to a list of servers (Continuous Delivery). In some cases where the production environment is made up of only a small set of servers, the Continuous Integration process may support production deployments, but in most organizations CI is used mainly by development and testing teams. When someone states they are doing Continuous Delivery, they are saying that they use their CI process to execute a deployment script.

Application Release Automation (ARA) is designed to fully orchestrate the delivery of software including infrastructure and database updates, server configuration management, calendaring, roll-forward, rollback, security access and component packaging. A Continuous Delivery process may call an ARA solution to perform the orchestration of the deployment, replacing the one-off deployment scripts written by developers.

Learn more – download the whitepaper