Product

Home Product Main features Automated vs manual activities. The way to achieve compliancy.
Visit our brand websites for specific solutions

Versioning, automated deployment and Life Cycle Management for
Oracle OWB / ODI

Mainframe modernization and agility, using Life Cycle Management for
z/OS

Main features

Build Management

Build management orchestrates the complex software assembly, testing and packaging processes that go into producing the product executable. Automated environments for builds are a common feature of systems today. A centralized, reliable build strategy is therefore crucial for an effective ALM approach. Continuous Integration is one way of doing this.

Continuous Integration

Continuous Integration is an extreme Programming (XP) development practice where members of a team integrate their work frequently; usually each person commits their code changes at least once daily - leading to multiple integrations per day. Each integration is verified by an automated build (preferably also including unit tests and code checks) to detect integration errors as quickly as possible such as, for instance, a failing unit test.

Early feedback on broken builds or failed tests is very important since such information will dramatically reduce the time to fix such errors, and, consequently, will also cut down on overall development time. It is obvious that it will take a lot more time fixing code that was written a week ago, compared to code that was just committed to the version control repository only minutes ago. Getting the sources turned into a running system can often be a complicated process involving compilation, moving files around, loading schemas into database, and so on. It is clear that these tasks should be automated to run on a dedicated server, so that a repeatable build process can be started as soon as possible after the code-base in the versioning system has been changed.

 

Automated Build and QA

Continuous Integration gives projects early feedback on the quality of their code. As a result this will improve the end result placed in production and cut down the complete development time. But the development process does not end with the integration build. The result must be tested on a QA level, rebuilt with other compilers or operating systems, deployed under different application servers, and tested on distinct versions of the underlying application database. These are error-prone processes and thus ideal candidates for automation. This is the only way to guarantee that the code used to create the build result after a Continuous Integration process is the same as the code deployed and running in a test environment. During the test you should identify the problems that also might occur during production. It is therefore important that your test environment is similar to the production environment. If this is not the case, it is difficult to predict what will happen in production.

Deploy Management

Traditional change management systems have focused on activities close to the developer, such as source code control, but few mechanisms were in place to support software deployment activities.

To be able to know which build version of the application must be retrieved from the build archive to deploy onto the designated target platform you need to automate the deployment of all your software assets. When you have automated the Continuous Integration and promotion to the Test level, it is obvious that the last (and most important) step in the development lifecycle is also a controlled process: deploy to Production. The production environment will probably resemble the test environments. However, you probably will not rebuild you application on the production server, and there will be probably more audit, notification and authorization involved before code is actually deployed.

The IKAN ALM solution solves complex deployment issues, like keeping clustered servers synchronized, or synchronizing applications with their database.

Lifecycle Management

Developing applications is not just about writing code. Once it has been developed, code must be tested, approved and delivered to the live environment. Depending on his/her profile, some users will expect their code migration to the live environment to be complete as soon as possible whereas for others it will only happen when the time is right. Therefore, a correct software change workflow process must be in place to fulfill the needs of the entire project team.

An IKAN ALM solution provides this assistance by auditing what has changed, when it changed, who changed it and who approved the change for promotion. IKAN alm is both the glue that holds together the various components and phases of the application lifecycle, and the oil that lubricates the smooth and efficient interaction of those components. It delivers an automated workflow to drive a continuous flow of activity through the development lifecycle and efficiently coordinates and streamlines development changes.

Approval Process

To improve the communication within the project team it is advisable to set up approval and notification processes for this last step of the lifecycle. It is a good practice to notify project members that a delivery to production will happen. It is a better practice to also setup an approval process before the production deployment, so that production operators, QA people and project management can audit and control this important stage in the roll-out process.

Even if you have a well planned and executed QA and audit trail, from time-to-time things may go wrong. Therefore it is not a luxury to ensure that there is a way back, so that in the worst case scenario production service levels are minimally disturbed. A well-defined and tested rollback process will protect you from nightmares like production shutdown.

Next: ArchitectureNext page