Last week we talked about Parallel Development. By applying some Best Practices we showed how you could several ODI projects in parallel and this without having to worry about merging.
Next step in the cycle is on how you deploy each individual project and more especially how you deploy often and fast with a minimum of overhead. Or how you put DEVOPS, being Continuous Integration and Continuous Deployment in practice.
Partial Build is the answer
The answer to this question is quite simple. Can you identify the what has or is changed compared to what you have currently in production? The answer to this question is to identify the modifications and there are two ways how you can solve that. Partial Build is the answer. What do we mean by Partial Build?
Well, you have two flavors:
- Partial Build: only the sources (objects) that were modified since the last Build will be rebuilt.
- Production-based Partial Build: only the sources (objects) that are different from the version on the Production Level will be rebuilt
Once we have identified the modified sources (objects) you need to tag them in your version control repository. This requires the possibility to do a partial tagging in your version control repository. That is why we use Subversion as a version control repository as Subversion has the ability to tag partially.
The next step is to deploy the modified objects to Test and/or Production environments. As a summary you can say this is from a process point of view quite understandable and simple. However if you have to do this manually, this will not be easy.
Our LCM4ODI solution automates that process for you. Using our solution you can easily version your ODI projects, you can identify modified objects and with one click you deploy the changed objects (sources or scenarios) to the desired Test or Production Repository. Fully automated, documented and repeatable!