DevOps
From APIDesign
(→NetBeans: The IDE for Admins and DevOps!) |
(→NetBeans: The IDE for Admins and DevOps!) |
||
| Line 35: | Line 35: | ||
== [[NetBeans]]: The IDE for Admins and [[DevOps]]! == | == [[NetBeans]]: The IDE for Admins and [[DevOps]]! == | ||
| - | Prior to version 4.0 the [[NetBeans]] [[IDE]] used the classical approach of fixed project [[classpath]] like other [[IDE]]s. While such approach is comfortable for [[Java]] developers (every one knows what a [[classpath]] is), it is very uncomfortable from the [[DevOps]] point of view: duplicating the [[IDE]] settings in a build script and continuous builder like [[Jenkins]] is just so much waste of time. The approach pioneered by [[NetBeans]] 4.0 where the [[IDE]] is just a [[GUI]] over project build script used by command line tool, is so much better when you care about your project from code up to the final bits. | + | Prior to version 4.0 the [[NetBeans]] [[IDE]] used the classical approach of fixed project [[classpath]] like other [[IDE]]s. While such approach is comfortable for [[Java]] developers (every one knows what a [[classpath]] is), it is very uncomfortable from the [[DevOps]] point of view: duplicating the [[IDE]] settings in a build script and continuous builder like [[Jenkins]] is just so much waste of time. The approach pioneered by [[NetBeans]] 4.0 where the [[IDE]] is just a [[GUI]] over project build script used by command line tool, is so much better when ''you care about your project from code up to the final release bits''. |
The project is that in common enterprises there is nobody who could care! Once a project is developed by a team one has dedicated build and release engineers and those take care of the build scripts. In some sense the more complicated the buildscript, the better, as that secures the build engineer job. On the other hand, to find a [[good]] programmer is hard these days and enterprises often hire people who can barely read [[Java]] (or other [[language]] used in the enterprise). To find a programmer who also understands some non-trivial algorithms without using [[StackOverFlow]], is almost like a miracle. Refusing such candidates because they don't have good enough [[DevOps]] skills - e.g. they cannot read and debug [[Ant]] or [[Maven]] scripts - would be too luxurious. There are other guys in the team to handle that. | The project is that in common enterprises there is nobody who could care! Once a project is developed by a team one has dedicated build and release engineers and those take care of the build scripts. In some sense the more complicated the buildscript, the better, as that secures the build engineer job. On the other hand, to find a [[good]] programmer is hard these days and enterprises often hire people who can barely read [[Java]] (or other [[language]] used in the enterprise). To find a programmer who also understands some non-trivial algorithms without using [[StackOverFlow]], is almost like a miracle. Refusing such candidates because they don't have good enough [[DevOps]] skills - e.g. they cannot read and debug [[Ant]] or [[Maven]] scripts - would be too luxurious. There are other guys in the team to handle that. | ||
Revision as of 10:46, 15 March 2018
Wikipedia defines DevOps as those people who unify software development and software operations and try to automate as much as possible. This essay is a note that reflects the NetBeans history from the DevOps point of view.
Contents |
NetBeans and Command Line
Since version 4.0 (released in 2005) the NetBeans IDE focused on support for external build tools. The first one was Apache Ant. You could create a project in the IDE and in addition to the configuration files, also a build.xml Ant script was created. The build script shared all the configuration with the IDE. As a result you could go to command line and type:
$ ant build
at the command line and the external Ant did the same thing that would happen in the IDE! In fact the (these days Apache) NetBeans was so tightly integrated with Apache Ant that it used the Ant internally as well.
I'd say that was a revolutionary step, but it appeared naturally. It grew from the deepest Jesse's experience - he knew how hard it was to configure Hudson, Cron or how the continuous build system of that time used to be called. With NetBeans the configuration was easy: Generate your project and your automatic build script is ready.
Isn't this a dream for a DevOps lover?
Maven and co.
Later NetBeans also started to support Maven. As the Maven is way more declarative (compared to Ant), it was much easier for the IDE to understand the build scripts written by other people without using NetBeans. As a result following magic was possible: Check a project from a Git repository out and open (yes, open, not import!) the project in the IDE. The IDE reads pom.xml and figures out everything - classpath, source level, Javac options, Javadoc configuration and more. Just by having maven-exec-plugin definition section the the pom.xml the IDE immediately knowns how to execute the project. And there is more. Again, as in the Ant case, the Maven is used internally and as such the products of command line vs. IDE builds are rarely different.
Btw. the whole project system is pluggable and extensible. As such support for Gradle, JDeveloper, Eclipse project formats has been written as well and works the same: No import, real open! But from my perspective Maven support remains the best.
The whole cooperation with Maven is so smooth that I call NetBeans the GUI for Maven! This must be heaven for a DevOps guy, right? Just write your pom.xml and the IDE as well as your Jenkins will pick everything essential up automatically without additional effort.
Two Way Editing
The DevOps nirvana continues once you realize you don't need GUI to edit your project configuration. Everything, options, dependencies, plugins can be edited directly and once the pom.xml is saved, the NetBeans IDE picks the changes up and updates its internal state to them. The command line mvn install build always does the same thing as the IDE. The editors see the same classpath, the same sources. These days this is common in the Android+Gradle world, but when we started, this was unique.
Just Set the Classpath Up
On the other hand, there are problems of this approach. Configuring the classpath of your IDE is no longer just about adding path to JAR file in a project configuration dialog (as usual in the other IDEs). If there is a problem, one has to got into the pom.xml (or Ant's properties) and change that. The actual classpath and other project settings are influenced by various properties computed and derived from one another in relatively complex and tool (Ant or Maven) specific ways. Just by changing a seemingly unrelated property one can change the whole project classpath significantly. As soon as the IDE notices that, it may decide to reparse the whole sources. That may mean to throw away the caches to adjust to such change, usually resulting in the whole source tree turning red due to missing symbols.
This is not clueless - one needs to know what is happening and how to fix the problems. Recently we at least realized that in Maven case, if one JAR is missing from the classpath, then it doesn't make sense to reparse at all - and the IDE waits for the classpath to be 100% complete.
NetBeans: The IDE for Admins and DevOps!
Prior to version 4.0 the NetBeans IDE used the classical approach of fixed project classpath like other IDEs. While such approach is comfortable for Java developers (every one knows what a classpath is), it is very uncomfortable from the DevOps point of view: duplicating the IDE settings in a build script and continuous builder like Jenkins is just so much waste of time. The approach pioneered by NetBeans 4.0 where the IDE is just a GUI over project build script used by command line tool, is so much better when you care about your project from code up to the final release bits.
The project is that in common enterprises there is nobody who could care! Once a project is developed by a team one has dedicated build and release engineers and those take care of the build scripts. In some sense the more complicated the buildscript, the better, as that secures the build engineer job. On the other hand, to find a good programmer is hard these days and enterprises often hire people who can barely read Java (or other language used in the enterprise). To find a programmer who also understands some non-trivial algorithms without using StackOverFlow, is almost like a miracle. Refusing such candidates because they don't have good enough DevOps skills - e.g. they cannot read and debug Ant or Maven scripts - would be too luxurious. There are other guys in the team to handle that.
Enterprise developers than just open the IDE and change the code. Save (which should preferably recompile the needed pieces) and try the changes. If they have to adjust libraries or change the build process they tell the build/release guys. That however means that the strongest feature that makes NetBeans IDE unique isn't useful for them at all!
NetBeans is the IDE for DevOps. With a sadness in my heart I used this to explain why NetBeans was always popular among smaller teams and individuals, but never really fly among enterprises.
TBD: Other IDEs and the old version.
Follow
