It’s been a while since I’ve been posting to my blog, so I’d like to appologize for that… not that anyone is really out there hanging on my every word ;-). So this post is going to be a bit of a grab-bag of things.
The first and most obvious thing to comment on is actually something I cannot comment on so any comments I make should in no way be construed as commenting on anything that is worth commenting on at all. Huh??!! Right. Now that that is out of the way…
Installers are important…
Duh! Of course they are important. How else can you deliver your product and ensure that it is placed properly on the end-user’s system and is configured correctly? The problem is that many companies tend to think of installers as an afterthought. "We just built this great killer-app… now how do we deliver it?" Because of this tendency to push it off to late in the process, it is often short-changed. A flexible build, delivery and install process is key to making sure that your "integration" team does not become a bottleneck.
How you’re going to deliver your product is something that needs to that needs to have a decent amount of up-front consideration. It can, and often does, affect how you actually architect and build the product itself. You have to ask questions like:
- Who is going to install the product? One of your highly trained sales engineers or the clumsy end-user?
- Is your product going to be delivered via direct marketing, an indirect channel, or offered via a shopping website with immediate downloads?
- How many different "editions" or SKUs (Stock Keeping Units) will you have? (Beginner, intermediate, advanced?)
- Will you be offering a trial version?
- Will your product be localized into other languages? If so, are all languages delivered together or separately?
- Will you offer a lightweight free version?
Nearly all of those questions above, and probably a few others I can’t think of right now, are ones we have to ask ourselves all the time. "Integration" is the process of bringing together all the various bits and peices from other teams and external third-parties and "integrating" them into an installable image. For many years there have been a plethora of tools out there that serve to ease the construction of these installation images. However, not many (if any at all) actually help in streamlining the whole integration process. Not that they should, mind you, but there is often a lot more to delivering a product than simply pressing F9, grabbing the resulting executable, jamming it into an installer project, build the installer and burn a CD or upload to your shop site. For many folks those steps are actually all that is needed due to the limited complexity of the product. When you compare that to what we in the DTG group have to do, that is far from an adequate process.
Over the years we’ve developed quite a few internal tools (built with Delphi and sometimes InterBase of course!) that help make this process easier to maintain and to make it, and this is a critical point, repeatable. If you cannot ensure that each time the process is run that it goes through the same steps in the same order every single time, how can you be sure of anything in the output. For instance, no "offcial" build is ever delivered from a developer’s machine. Official builds are always done on a single-purpose isolated system that is dedicated to that one and only task of building the product. Developers rarely, if ever, have direct access to this system. The "integration" team is responsible for the care and feeding of that system. That team is also responsible for maintaining what we call the "delivery database" which is exactly what it sounds like. It is a huge centralized database that describes which files get "delivered" where and what kind of processing needs to be done to them on the way. By extension this same database is also used to generate scripts that are used by the installer software to create an installation image.
I’ll try and talk a little more about this whole process in some upcoming posts, but for now I’d like to hear from folks what kinds of processes you’ve setup to streamline and speed the delivery and building of installers? Also, what installers out there on the market are your favorites? We’ve used for several releases InstallShield from Macrovision, but there are many others and we’re always evaluating new versions or new entries into the market. A few of the others we’ve looked at over the years is Wise, InstallAnywhere, and a new interesting entrant into the whole installer domain, InstallAware. There are many others; some free, some open source and other commercial offerings. What is interesting about InstallAware is that it is written entirely in Delphi! That’s really cool!
Huh? What’s that? It’s a term used to describe a group of bicycle riders, usually in some kind of race, such as the Tour De France. Peloton is also the code name for the upcoming release of JBuilder. (What! This is a Delphi blog! Why are you talking about Java??!). Yeah, yeah, I know. However, since the formation of the Developer Tools Group here at Borland, I’ve had the privilege of working closer with the Peloton team here in Scotts Valley, CA. In many ways my role has expanded a bit and I now keep an eye on all the various projects going on in the DTG. Closely watching these other teams (this include the InterBase team) has been very enlightening.
The Peloton team had a daunting task ahead of them. They had to, essentially, recreate almost the whole JBuilder experience on top of the open source Eclipse platform! The face and character of the Java market is shifting dramatically and the move is on to open-source. The maturity and usefulness of all the various bits and pieces of open-source are finally reaching a critical mass. The problem, however, is that this new world order in the Java space doesn’t really have "order." It’s probably best characterized as being the "wild-west." The possibilities are nearly endless, but the dangers and pitfalls are many. There needs to be a trailblazer and a regional "marshal" to help establish some order and sanity to this new frontier. Take the Eclipse effort. Clearly the Eclipse IDE was first and foremost built to be a Java IDE. However, some of that is changing with the uptake in the adoption of the RCP (Rich Client Platform) for creating non-IDE type products. There is also the CDT (C/C++ Developer Toolkit), which is a cross platform C/C++ IDE tool.
However there is a bit of chaos. Enterprises don’t like chaos. Even many small to medium developer shops cannot afford added chaos to their development teams. By chaos, I’m referring to the whole open nature of the Eclipse platform. This is not an argument against open source at all, but merely an observation of reality. We’ve been speaking with many of the current and past JBuilder customers; For the ones that have moved to Eclipse, they are finding that "free" is by no means "free!" There are even some companies that have some of their top talent dedicated to defining the official Eclipse platform and plug-ins the development teams are going to use. That is amazing to me! You now have companies where development tools are not their core business, and most of them, software isn’t even their core business. They’re banks, investment firms, hospitals, government agencies. They’re not in the business of selling software let alone assembling or building development tools! Software is merely a necessary tool that the company uses to remain competitive in their respective markets. This is where Peloton (aka. JBuilder) will step in and fill the gap. By providing a certified and preassembled Eclipse environment, we can help many of these companies get back to focusing on what makes their businesses successful.
Peloton is not just a simple thin coating on top of the Eclipse you can go download for free right now, but it is also the evolution of the whole JBuilder product line itself! It is interesting to note that the first 3 versions of JBuilder were actually built on top of the Delphi IDE! (Hah!! There’s your Delphi reference!!). Starting with version 4 (there was a 3.5 in there… but let’s keep this simple), JBuilder shifted to what was called the PrimeTime platform, which was an all Java IDE platform. So from version 4 up to JBuilder 2006, it was based on the PrimeTime core. Now, we’re just doing the same thing again and moving to a new IDE core again and this time we’ve chosen the Eclipse platform. There was significant effort and emphasis placed on making sure that your existing JBuilder projects can be easily and seamlessly carried over to this new version. The DTG has always been about making sure our customers were not left behind and are provided an avenue to the latest technologies. Just like Delphi and C++Builder, JBuilder has held to this equally as well. If you’re at all interested in the upcoming release of JBuilder or have been using a older version, I would strongly suggest you look into purchasing JBuilder 2006 with Software Assurance. Everyone who is on SA when Peloton is released will get it as part of their SA agreement.
There has been some recent bruhaha surrounding the DTG’s BDS published roadmap. I will say that we’re currently in the process of review, re-alignment, adjustment and/or clarification of the currently publised roadmap. Industry landscapes can change, priorities can shift, so maintaining a stagnant roadmap is not in anyone’s best interest. Likewise, radical departures from an existing publised roadmap are equally, if not more, damaging. "Balance" is the watchword of the day… Very soon we’ll be announcing the opening of another online Delphi survey. Nick Hodges has been frantically gathering input about what to place on it from all those involved from the various teams. Changes are not made on a whim, but we are actively evaluating everything we’re doing and where we’re going. This is, in fact, a continuous process and something we’ve done for many, many years.
Busy, busy, busy
I just want to reiterate that the DTG continues to be filled with a flurry of activity. For instance, we’ve just hired a new head of marketing who is fully and solely dedicated to the DTG! Yeah, folks it’s been a while on this one… We’ve also opened many positions on the documentation team. So if you’re a technical writer, here is one of the positions to send in your resume’ or CV. We also recently filled a position on the Delphi compiler team. There are some openings available on our integration team, so if you’re experienced in writing installers, and would like to help define new, modern ways to install, update, and deliver Borland Developer Studio, be sure to send your resume here.Posted by Allen Bauer on October 26th, 2006 under Uncategorized |