Lessons Learned: ODI deployment automation

Last week we talked about partial build (and deployment).  Partial Build gives us the ability to just select these ODI objects (and dependencies) that have been changes since the last “Build”.

The next major step is deploying all or just the changed objects to a Test or Production Repository. Before you can do that you need to have your Architecture in place. What project streams do you have, what  is your Life Cycle and what are your target Repositories? With project streams we refer to how your development is organized: one stream for ongoing development, a stream per release and one for emergency changes or hot fixes.

Project streams reflect how your version control repository trunk and branches look like.

With Life Cycle we mean what and how many Test or QA levels (Repositories) you have and what Production levels (Repositories) there are. Levels are logical steps. And to each logical step one or more physical environments can be added. Key question is what you want to do during these deploy actions.

In test by example you still want to deploy source objects, but in production you just deploy scenarios.

  • Do you want database updates to be part of a deploy?
  • Interested in running automated tests as part of the deploy?
  • Anything else?

 

Lesson learned is that you first have to think (architecture!) how you want to develop and how you want to deploy. Once you have defined your life cycle process you can start to automate it. Automating will make your life cycle process cost effective, qualitative, repeatable, documented, verifiable and reliable.  And last but not least it will allow you to deploy more frequent and it will give you a faster time to market for your business

Get free insight!

Let's analyze your current development and release process, and show you how to make it much faster and 100% reliable.

Yes, I want insight

Do you want to recieve the latest news and updates?