IET DevOps Suite
 |
The IET DevOps Suite is an integrated family of software tools that significantly improve Gen developer productivity and the quality of delivered applications. This is achieved through automation of key development processes and a modernised Eclipse based integrated develoment environment covering application development and key DevOps tasks. |
Many organisations are now revising their development practises for greater tool integration under the banner of DevOps. Whilst most users of IET tools will already be automating many of the steps in the life-cycle, in the context of DevOps they may also want to consider greater integration between tools.
What is DevOps?
DevOps is a set of practices that combines software development (Dev) and IT operations (Ops) which aims to shorten the systems development life cycle and provide continuous delivery with high software quality.
Whilst there isn’t a formal, universally accepted definition of DevOps, the Software Engineering Institute have suggested defining DevOps as "a set of practices intended to reduce the time between committing a change to a system and the change being placed into normal production, while ensuring high quality".
The graphic below is used to illustrate the continuous cycle of development and operations.
Typical goals for DevOps include:
Automation
A key aspect to achieving these goals is effective automation of the build and release processes, including effective configuration management and version control of the software artefacts. It is beyond the scope of any one tool to automate all of the processes involved in DevOps, so effective automation relies on using multiple tools and products.
A key part of successful DevOps is continuous integration and continuous delivery (CI/CD).
Continuous integration (CI) is a process in which developers and testers collaboratively validate new code, and it automates the code, build and test stages.
Traditionally, developers wrote code and integrated it for testing, sometimes monthly or even less frequently. To avoid the problem of having to fix code that was written weeks or months before, CI uses automation to integrate code continuously (or much more frequently) in the release and deploy stages.
Continuous delivery (CD) is the process of continuously (or frequently) creating releasable artefacts to test that the software product is executable and facilitate testing.
In an ideal world, and with the benefit of an unlimited budget, you could contemplate automating every process and integrating every tool. In the real world and with restricted budgets this is usually not achievable, especially when most enterprises are creating software using a diverse set of software development tools, for multiple platforms and with teams spanning multiple locations.
It is important therefore to focus on the most beneficial automation and tool integration for the individual enterprise’s own environment taking into account existing tools, processes, culture and maturity.
Candidate processes for automation should be identified and prioritised, for example by asking:
Many of the processes involved in managing and deploying a change to a Gen application are time-consuming and highly reliant on the skills of a few individuals and therefore key candidates for automation.
The Challenge with Gen
The majority of software development approaches and tools involve creating source code that is stored as text files and then compiled/built into an executable. Many tools are available for version control and build automation, and because the source code is file based, standardised tools are able to automate the processes without needing to understand the precise underlying content of the specific language or tool used to develop the source code.
Gen is very different in this regard. The ‘source code’ is not the generated C, Java or COBOL but the model stored in the encyclopaedia, or more specifically, a highly structured and interrelated set of objects, associations and properties that are stored in a proprietary format in a database.
Standardised configuration management and release automation tools do not have direct access to the software artefacts in the Gen models and they are only of use once the 3GL source code has been generated from the model.
The processes involved in managing and building Gen applications are very specific to Gen, for example building applications from multiple models, object migration and analysing the impact of changes to the model in terms of what programs require regeneration. They not only require a very good and in-depth understanding of Gen, but their successful execution is also reliant on a good understanding and documentation of the Gen model and application architecture and contents.
A fundamental part of successful automation of the code, build and test phases of development is source code control with accurate versioning of the changes made. Whilst with Gen you can determine what was last changed, automation of the DevOps processes requires more precise control. Specifically, it is vital to have the ability to associate the changes to individual objects back to the originating change requests so that the scope of a release of the software in terms of changes to the Gen models can be accurately assessed to determine what code needs to be regenerated. Without this you are left with needing to regenerate all of the changes irrespective of whether the changes are completed and ready for release. Lack of true version control can be acceptable for a ‘big bang’ release of all changes with a mass regeneration of code, say once per year, but is not compatible with the desire for frequent and agile releases of smaller packages through the life-cycle, for example with Continuous Integration / Continuous Delivery.
IET DevOps Suite
IET’s suite of tools are focussed on supporting the planning, coding, build and test stages of the DevOps life-cycle. These are summarised in the table below.
| DevOps Phase | Tools | ||||||
 |
|
||||||
 |
|
||||||
 |
|
||||||
 |
|
||||||
 |
|
GuardIEn and DevOps
GuardIEn was designed from the ground up specifically and uniquely as a change and configuration management solution for Gen. It automates version control, change management and automated build and release management.
With GuardIEn the architecture of the project is precisely defined in terms of the development life-cycle, model architectures, promotion rules and steps required to automate the build and deployment.
GuardIEn can either be used as a standalone tool or it can be integrated with other products including software configuration management, release automation and change tracking tools.
The key functions in GuardIEn of relevance to DevOps are described below.
The development cycle starts with planning or requirements definition. In GuardIEn a Change Request is defined to identify the business or technical requirement.
As the developer develops the changes, new, changed or deleted objects in the Gen model are automatically associated to the GuardIEn Change Request via the GuardIEn Upload Assistant which detects changed objects and establishes new versions for them. GuardIEn versions allow you to see precisely what each separate change involved, for example changes at the action diagram statement level.
A GuardIEn Release Pack is a grouping or package of one or more Change Requests that are to be promoted together, for example as the scope of a new release or update to an application.
A GuardIEn System Update is used to automate the build process via the execution of various steps, for example, object migration, impact analysis, code generation, external action block compilation, build and any other process required to convert the Gen and external sources into an executable system.
GuardIEn System Updates can be executed on demand via the GuardIEn client user interface or scheduled to run automatically at certain intervals or when triggered. This forms the basis for automated continuous integration since the GuardIEn SU is scoped to promote all of the objects changed within the scope of the SU via its association to the Change Requests.
Whilst a GuardIEn System Update can automate all of the build and deployment steps for a wide variety of application targets, often an enterprise will use a standard tool for release deployment. To enable Gen to participate in the enterprise-wide standard process, GuardIEn provides interfaces to enable handoff of the build process. Standard interfaces are available for commonly used products like ChangeMan, Endevor, Harvest and ISPW.
Tool Integration
Most enterprises will have a variety of tools that support the development life-cycle, from requirements / change / issue tracking tools used for planning and defining changes through source code version control and configuration management tools, testing tools to build / release automation.
Whilst changes can be defined within GuardIEn as Change Requests, often there is a desire for a single point of definition that spans multiple development projects and technologies, so a more generic product might be considered.
At the other end of the cycle, whilst GuardIEn is often used to manage the build and deployment of executable code for Gen applications, where the application is developed with multiple technologies or there is a requirement for production deployment to be managed by a specialist tool, various interfaces and points of integration are available in GuardIEn so that it can manage those steps that are specific to Gen (like object migration, impact analysis and code generation) and then handover to another tool for more generic steps like compilation and deployment, or QA points such as sign-off and peer testing review.
To enable the integration between GuardIEn and other tools, various high-level APIs are available in GuardIEn.
There are web service APIs that enable the definition of GuardIEn Change Requests and Release Packs for use when another tool is used for change planning and scoping.
There is also a web service API for defining and executing a GuardIEn System Update for use when the Gen aspects of a build/deploy process need to be invoked from an external tool, for example when co-ordinating the promotion of changes within Gen and other development tools.
In addition to the standard GuardIEn interfaces described above, GuardIEn can also be customised to work with other tools using various exits and integration points in the product.
Conclusion
Organisations that are aiming to implement or improve their DevOps processes can include Gen applications within the scope of their DevOps tooling. Generic source code and build automation tools struggle to offer meaningful and reliable automation of the Gen processes due to the complex and unique nature of Gen. However, with the use of IET’s tools, these processes can be highly automated to deliver the goals of DevOps, and also integrated into the broader toolset chain in use by the organisation.
This content is also available in pdf format: DevOps Tool Support for Gen
