Application Development in a DevOps Enterprise
Comment (1) Visits (14180)
Unless you have been hiding under a rock, you have been seeing many communications of late regarding DevOps. And the messages you hear from us at IBM emphasize that DevOps covers a lot of ground. It starts with planning, then development and test, then on through release management and deployment, and all the way to production monitoring and optimization. And then all the way back to the beginning again, with a feedback loop that informs the next iterations of planning and development, about what your customers (be they internal or external) are really experiencing as end-users.
We also talk about a broad array of products and services that focus on optimizing the steps along the way, and on integrating data end-to-end and enabling all of the various disciplines to collaborate more effectively.
In all of that breadth and complexity, here’s a poser: Clearly your choices regarding the tools that you use to support planning, testing, release management, deployment automation, monitoring, optimization, feedback, and collaboration can make a significant difference to your DevOps outcomes. But what about the tools in which developers spend most of their time? Do IDEs matter?
I think they do, and here’s why: DevOps is all about
The faster your developers can turn out high-quality code, the faster you get to market. Writing good code, fast, is primarily about two things:
Unless your applications are small and simple, your developers should be using tools that help them understand, as quickly and fully as possible, the implications of any potential design decision or implementation choice. That involves looking at dependencies and other relationships from several perspectives and across the entire breadth of the solution that might be affected. Only when they can do that quickly, can (most) developers make large numbers of high-quality decisions in short time boxes.
And once decisions are made and it’s time to implement them, any developer’s implementation speed will directly reflect things like…
In other words: their speed relates directly to the mechanics of how they perform the kinds of micro-tasks they will perform over and over again, scores of times -- or even hundreds of times -- per day. So they should be using tools that do things like minimize gestures-per-task, maximize percentage of generated code, and provide pervasive assist-and-instruct capabilities.
Your ability to pivot quickly may be enhanced if
So your developers should be using tools that help them understand, as quickly and fully as possible, the implications of any potential design decision or implementation choice. (Yes, I just repeated myself. But I did it on purpose, so it’s OK ;-) That way, they can execute their maintenance tasks more quickly and with higher confidence of not introducing side effects. Meaning they can more quickly return their attention to innovation work.
And if you run a heterogeneous mix of applications implemented in multiple languages on multiple platforms, your developers should be using tools that afford a common user experience across a wide range of languages, platforms, and development paradigms (or “programming models”) such as SOA, Web, and mobile. Then, if and when they need to move to a new language and/or platform and/or paradigm, they only need to learn (or re-learn) the language and the platform and the paradigm, and not the muscle memory that is associated with using their IDE.
Moreover, if their tools have the unique capability of being able to debug complex solutions whose parts are comprised of pieces of code written in several languages running on several platforms – and I am referring here to the ability to actually step from one language and platform to another in a continuous debug session – you should see a further reduction in percentage of time spent on maintenance.
So your developers should be using tools that help them prevent defects, and more quickly address those that do get introduced. Here again wizards and other automations that generate code play a role. As do code comprehension tools. But so do capabilities such as static code analysis, unit test automation, code coverage analysis, and dynamic (e.g. memory usage and performance) analysis that speak to early problem detection.
Being agile (reprise)
Another concept that goes hand-in-hand with ‘agile’ is continuous integration. This is where build and unit test are done on a regular, periodic basis to pull together all the contributions across a team (or across multiple teams, in the case of large, complex solutions). When everything passes, the results are shared back with everyone so that the developers have access to the latest set of integrated changes that work properly. When there are failures, records are kept and everyone can understand why the failure happened, and learn from it. (Note that DevOps looks beyond continuous integration, to the notion of continuous delivery. But that is beyond the scope of today’s post.)
In order to do continuous integration well, developers should be using tools that not only have built-in facilities for unit testing, static analysis, and code coverage but also
Market shifts are changing how software development process, infrastructure, and tool decisions are made. Developers' level of influence on LOB decision makers is ever-increasing, regarding all aspects of the delivery stack (cloud, mobile, middleware, processes, languages, tools).
Hopefully, in keeping with their growing influence, developers also recognize their responsibility to take a broad, cross-disciplinary view of DevOps and its challenges, and ensure that their choices, recommendations, and day-to-day actions contribute to optimizing DevOps end-to-end.
Accordingly, they should ensure that their IDE - the primary tool in which they spend their days - is not only seamlessly integrated with planning, collaboration, change management, SCM, build & deployment automation, dashboards, and reporting, but also provides them with the best tools for delivering code rapidly, with high initial quality, and with awareness of its potential down-stream impacts.
Accordingly ,they should be giving serious consideration to the Rational family of IDEs which includes Rational Developer for System z, Rational Developer for i, Rational Developer for AIX and Linux, Rational Business Developer, and last but by no means least: Rational Application Developer, the IDE for distributed Java, JEE, Web 2.0, and SOA development that as of 2012 had won the Evans Data Corporation IDE Users Choice Award 6 years running.
About the Author
Bill Smith is currently the Product Lines Manager for Rational Integrated Development Environments for distributed systems and IBM i. He previously managed the Rational Software Architect product line. Bill is in his tenth year with IBM (and his thirteenth with Rational). Prior to joining Rational he worked for a number of companies in the healthcare systems industry in roles such as developer, VP engineering, account executive, and product manager, capping that career arc as the Chief Compliance Officer for an online health information and physician services organization. Bill holds a BA in Math and Economics from Whitworth University. He is based in the Portland Oregon area.