What can you do if given less time than you really need to deal with a task – but no additional resources? Our technical architect, Gerold Glaser, was presented precisely with this problem. In order to solve it, he wasted no time at all in restructuring the development process. His method, based on automation and very close cooperation with the customer, is so successful that it has since become our new standard. He explains here in an interview with Michaela Alker how exactly this came to pass and what challenges await application developers in the future.
Michaela: Gerold, what does “continuous delivery” mean?
Gerold: Technically, continuous delivery (CD) consists of three areas: continuous integration, continuous delivery and continuous deployment – but generally only continuous delivery is referred to in practice.
Continuous integration has been a reality at Porsche Informatik for many years. As soon as a developer makes a source code change, an application package is prepared, which then passes through the widest variety of manual stations in a pipeline.
Until now, however, the next stage was neglected here, meaning that it was often a very long time from preparation until product deployment. In our corporate strategy 4.0, we set ourselves the target of becoming much faster and shortening the release cycles substantially.
What was the trigger, the initial impulse for you then to implement this missing step as well?
The trigger was the task to develop an application with two people within three months. In spite of all our deliberations and endeavours, we were only able to make a commitment to the client at that time to implement the project within five months. Since the client was unwilling to deviate from his target, I was given the task in-house to come up with a solution for implementing this assignment.
Did this put you under a lot of pressure?
To begin with, yes, because I didn’t know exactly where to start. A process chain needed to be completed. But it soon became clear to me that I would not be able to complete this task with a conventional mindset, using traditional means. The schedule and budget had been fixed, so I had to make do with the resources available.
After a period of intensive effort, I then developed the following idea: Time savings were only achievable if we established a new form of cooperation with the client and transferred part of the manual pipeline into something automated to the greatest possible extent. This gave rise to co-creation, a process in which we consult with the customer on a weekly basis.
How was it previously? What sort of time frame did clients have to reckon with from the idea to completion?
Formerly, one to two years could pass from order placement through to release.
When you conceived this idea, was it clear how much time you could save with this new working method?
Not to begin with, because we first had to cooperate with the client in fathoming how we could jointly optimise our modus operandi and which time-intensive steps we could omit, without suffering any loss in quality.
What means did you use for implementation and what was the greatest innovation for the customer in this process?
We employed the OpenShift/Docker architecture. It must be ensured in the core process that there are no more manual to-dos and that the individual work packages are of a high quality. The release process on the customer side also had to be changed.
One new feature is that the clients themselves accept the changes digitally in the development environment and then start the deployment process themselves as well. Use of the new version in the production environment is then initiated fully automatically.
BrowserStack is used to test the core processes of applications fully automatically on different terminal devices and with various browsers. Once everything is OK on all devices, i.e. when all tests are finished, the application packages arrive in the QA environment for acceptance by the clients themselves.
Does this also work reliably with sensitive systems?
Naturally, we also then installed a security network, a so-called “A/B deployment” system. Only a specific circle of users at the customer receives a new part of the application. This means that there are always two versions on the market. For Internet applications, there is a percentage key – 10% of the apps receive the latest version. If this runs well, then all other users receive it automatically. If it is not accepted or a specific user group does not react well to the changes, then no further rollout takes place.
For our trading applications, such as the VU2, CROSS and Retailer apps, there is always a three-stage pilot programme, because these are very critical applications. This prevents a change from laying low a whole country or a whole customer group all at once. Another important aspect is that our applications must always be available. In other words: zero downtime!
Once you’d reached a consensus, how fast were you actually in the implementation?
Thanks to the establishment of co-creation, weekly acceptance cycles and a high degree of automation in repetitive steps, we ultimately achieved a 50% time saving. In actual fact, we were so fast that we finished several weeks before the target deadline!
Wow, congratulations! But doesn’t such a result set a very high standard for all other developments?
Not really, not once you’ve become accustomed to the new way of working and you cooperate so intensively with the clients. The ongoing coordination and high degree of automation simply make the process much quicker than before.
Where did you receive support from? Was your idea promoted within the company?
The company management was completely behind the idea from the very start and did a lot to expedite and establish it. If an idea has added value for the customer in reducing the time-to-market and also leads to greater customer satisfaction, you naturally receive the management’s wholehearted support – and the result is a real success story.
A real success story – rewarded with the Change Award in the category „Quality“.
What was the effect of this change on your own way of working, and what effects has it had in general on the role of a developer?
In future, an application developer must have the ability to see everything from the customer’s perspective while also having a complete technical understanding of the subject. This means that the traditional role of an application developer will have to be supplemented with soft skills, knowledge, creativity and idea generation.
Application developers will always have to bear the future in mind, because, if an application is good and very well received, then it must also be endlessly upwardly scalable at any time if the market uses it intensively. In addition, it must always be possible to react flexibly to the market: If an application is no longer accessed, it must also be possible to downgrade it, i.e. the application must be downwardly scalable as well, and many small changes must not have any global effects.
Overall, this is then referred to as BizDevOps – the amalgamation of development with business and operation.
If you have become so fast, does this mean that fewer employees will be required in future?
Even if we are five times quicker with the time-to-market than before, we still need plenty of staff, because the customer requirements are endless!
And what is your vision for the future?
In future, we will be employing AI (artificial intelligence) and VR/AR (virtual and augmented reality) in order to implement customer needs even more effectively and efficiently. Another example is Google Vision: Software will no longer be programmed in future, instead it will be trained in almost the same way as a dog. Application developers will potentially be training modules rather than developing them themselves.
This means that an application developer will be faced with the challenge of always being on the ball in future, in order to be able to employ tools such as AI/VR/AR in application development in a targeted and time-saving manner. Tools such as Google Glasses & co. will allow additional operating elements to be integrated into our applications.
