May 22, 2013
Entrepreneurship = Persistence
Continuous software development has arrived. Users either struggle to find your specific process to create their own software; or, become software consumers. The entrepreneurial journey has again led to this trend, and the idea of an End-User Software Club is more relevant now then when first proposed. So, LaSalleMart development will continue.
Zach @ St. Lawrence Market
Interesting morning. Fell asleep at my keyboard this morning. Opened my eyes groggily and it was 45 minutes later. Then I pinged Zach and had an expansive, hour long Skype chat.
Midway through, I said that our conversation would make for a decent podcast. Well, in lieu of the podcast-that-wasn’t, I want to let you in on our conversation.
Zach Atkinson is a programmer-slash-consultant in Whitby, just east of Toronto. He is getting paid zippo-nada-nothing for all the heart-and-soul that he is pouring into LaSalleMart, including the first LaSalleMart Canada live site install (http://KearnsOptical.com). Zach’s sweat equity in LaSalleMart is tremendous.
The pressure today is to fix the existing PayPal Pro payment method.
Reminder: LaSalleMart is a fork of Tienda 0.8.2. At this point LaSalleMart is virtually all Tienda. There are differences, which are more overt now.
PayPal Pro is something that is pure Tienda, and something is fucking up. How else to say it? Not on Zach’s site, but on my old Tienda Distro site at h2oAudio.ca. This site is slated to migrate to LaSalleMart, but before we Press Da Button on that, we have to fix PPPRo. I suspect the problem is really the interaction between the plugin and the component. I’ve already made cosmetic changes to this plugin. Oh well.
We also have an urgent need to create a brand new Canada Post shipping plugin. We can’t wait any longer. The h2o site, and a local client I’ve had since my early Joomla days, need PPPro and Canada Post. Zach has graciously answered my call for help, and has refused offers of $$. Remember that when you talk to Zach. Like Cab Calloway said, he’s got the heart as big as a whale.
Zach started complaining about checkout. Hey, take a number! He said we should go through the Amazon checkout to get ideas. I started laughing, I’ve done this how many times already? I said Amazon has Conditional Branching in checkout. If you do X, Amazon’s checkout will respond with Y. Furthermore, we need LaSalleMart to handle a matrix of rules. Such as special checkout pathways for certain classes of customers, location of buyers, etc. LaSalleMart is absolutely, completely inadequate to the task. To cut to the chase, to achieve the Amazonian/Magentonian features that are so often expressed to me, we must avail ourselves to all of Joomla, not just confine ourselves to the component-module-plugin paradigm.
We talked about busting up the LaSalleMart admin for the 2.5 conversion. Discrete components let’s us know that we finished a piece of the admin. Don’t want to do it in one fell swoop. Also, gives us the freedom to stick to the original Tienda code, or start refactoring. Or both! So, looks like we’ll have com_lm_adminconfig, com_lm_adminorder, com_lm_adminproducts, etc instead of just /administrator/components/com_lasallemart for Joomla 2.5.
At first we’re gonna have to install each component individually, and Live Update each one individually. Absolutely irritating and infuriating! However, we are on a road to somewhere, and that somewhere is called “Package Management” — which is yet another reason why Club Commerce should embrace the Square One project, by contributing labour and money to it. We’ll get there!
Not that I pontificated to Zach about this during our call, but I will in this post (!) that the conventional way we perceive Joomla — “we” being my target Club Commerce Members of consultants and site owners — is positively medieval. Owning/running the websites, and vertically integrating into software development opens up wide vistas of opportunities.
We both agree that steering LaSalleMart into mobile is critical. However, first things first: we have to convert to Joomla 2.5. Mobile is where Club Commerce as a funding model is so important. We’re (“we” = Members) going to have to do all this stuff within my Club and not depend on the emergence of components or technologies to ease our burden. Responsive design is only the beginning. We have to understand buyer behaviour with the different mobile devices, and align our sites to these behaviours. Club Commerce has an incredible potential to blaze the trail with Joomla ecomm on mobile. To me, the first step is to understand the different behaviours people exhibit on different mobile devices. The idea of treating mobile devices like the desktop is wrong wrong wrong!
In the same breath, I suggested embedding media into LaSalleMart. Why not put video into the admin at pressure points where people get frustrated. Why not put video into checkout! What about the advent of Internet TV? Yes, I’m thinking ahead.
Bob @ St. Lawrence Market
Zach asked me pointed questions about builds. Look, there’s something y’all have to understand about Club Commerce: it’s a place where the Members have BOTH the websites AND the software. The whole is greater than the sum of the parts. Having BOTH the sites & the software is EXPLOSIVE for our online businesses. I’m in the same boat as Zach, because I have clients too! If Zach has 100 sites under his wing, and I have 100 sites under my wing, then how to do we manage the upgrades? How do we do backups/disaster recovery? 100 sites that have weekly updates of 20 separate comoponents needs a management solution beyond “initiate Live update 2,000 times per week”. The solution: we build an pipeline. What will end up happening is all the sites under our wing will be managed as custom Software-as-a-Service sites rather than as traditional Joomla sites –> WHICH IS EXACTLY WHAT WE WANT.
Something else Zach brought up was doing seminars. Old fashioned seminars where attendees even pay to get in and then sign up as clients on the way out. Members-only classroom style get-togethers. Joint JUGSWO and JUGT events that Club Commerce sponsors. I’m all for trying out the first, especially if people are vetted. Extremely excited about the second two. Joint events is not pie-in-the-sky shit, both are Very Real possibilities.
I said that the Toronto area could end up being one of the world’s hotbeds of Joomla ecommerce, given that we are here and so can do physical meet-ups. If a third to half of my Club Commerce Members end up being from an expanded GTA area, we could blaze quite a trail to the benefit of my Members, and the broader worldwide Joomla community. And you thought I lacked ambition!
Working on LaSalleMart’s first live site with Zach Atkinson highlighted a problem with Akeeba Live Update.
Live Update is a subset of the Akeeba Release System. LU allows you to update LaSalleMart from your Joomla Administrator, instead of trudging to my download site, logging in, downloading, etc etc.
It really works. There’s an icon in the LaSalleMart dashboard that tells you if you have the latest version. If not, you click to the update page.
On my end of things, every time I have an update, I have to go to my ARS admin and fill out forms. Which is fine if I have one new release every week or two. But, what happens when I have a new release daily? Or even — gasp! — more than one per day? Then, it’s a major PITA to update the ARS admin.
A new release per day? You betcha! If I make one small change — which I did late this afternoon — why wait to release it? Philosophically, I want all LaSalleMart sites to have my changes asap. Continuous Integration, Continuous Deployment — the key word is “continuous”!
GitHub.com is great. We update the repo(s), and the code is ready for Phing.
Phing is proving to be so powerful that I’m starting to consider it a weapon. Once the LaSalleMart repositories are PUSHed, it takes mere minutes to get all three LaSalleMart flavours uploaded to the Akeeba Release System folders.
However, updating my ARS admin is proving to be a bottleneck. In fact, knowing I have to update it has caused me to delay running my Phing builds. This is a Very Bad Behaviour: the antithesis of “continuous”.
The Joomla installer a bottleneck. Not just physically; but, it is a nasty limiting mindset. I have Grand Plans to bypass the Joomla installer completely. However, in the here-and-now, we are using the Joomla installer; and, using ARS.
So, after achieving “continuous” with GitHub and Phing, how to I overcome the ARS bottleneck? Well, did I mention that Phing is very powerful?
Phing does databases. Phing can talk to the ARS database directly. The Phing task is called “pdosqlexec”
So, Phing UPDATEs the ARS database directly. Look Ma, no Administrator! Bada Bing, Phing uploads the new ZIP files, and then does the UPDATEs right after.
But, I cheated. As Nicholas will probably read this, I better fess up! Phing UPDATEs #__ars_releases only. I don’t bother adding brand new releases, I just pretend that my latest ZIPs are the very first releases. Saves a lot of bother this way, although not what ARS intends. Well, I use ARS as a conduit between code origination and final upstream code, rather than a software release mechanism. It’s continuous deployment, baby!
I ended up tweaking manifest.xml and defines.php (and a few other things). Most fun reserved for phiguring out Phing. A journey learning how-to set up the automation. But, whooooooaaaa, now that I have the automation in place, it sings!
LaSalleMart updates can be on your site within 10 minutes of the GitHub update. With the automation, I have no extra steps with the Phing builds, except to update the separate parameter file (which is now a single point of entry instead of 3 separate files).
Forget about waiting for releases. I do ‘em as I go along. Continuously.
Even via good ol’ Live Update, we deploy continuously!
This is the modern way of doing it. Phing & GitHub are powerful ways to make it happen for us.
UPDATE (June 26, 2012):
From Nicholas:
The BleedingEdge category type was designed to remedy this issue. Just create a new directory with the version number and upload the files in it. Coupled with the Automatic Descriptions feature it’s upload and publish with zero clicks. I have a Phing task called ftpdeploy in all my components. Issuing a new dev release is as simple as “phing ftpdeploy” for me
Feel free to browse my Git repos and salvage all the Phing code you need
[https://akeeba.assembla.
com/code/akeeba-release- system/subversion/nodes ]
Nicholas, awesome! I will take a look at this Thank you!
When there are updates, you should have them. Why not just get ‘em when I have ‘em, instead of waiting for me to decide it’s time to create a software release?
Technically, it’s possible. Phing does FTP uploads, so why not upload to your server? Phing also pushes to Git repos, to why not push to your own repo, and then you can grab it there?
The only way to figure out Continuous Deployment is to do it.
The immense advantage of doing software development and having the live websites is the ability to implement Continuous Deployment (aka Delivery).
I’m thinking crazy thoughts because we are a Club; and, we have control of both the downstream and upstream. That is, we control the code, and we control the individual sites. If we have hundreds of sites, then why not have a bunch of Phing scripts launched by Jenkins to FTP upload the changes to each individual site? Unthinkable with other extensions, but we are building for ourselves, so we can do things differently. As well, we are designing our development process to deliver small pieces of code all the time, instead of delivering huge blobs of code infrequently.
I’m thinking that I have to bust up my “LaSalleMart-Core” repo into many smaller repos. If we update a language file, then we should get that on sites right away (I’m thinking of the language file as a way of delivering more help as we go along, for instance). Other files should not be delivered instantly, b/c there should be more of a testing/QA process. But ultimately, these need to be delivered too.
So, there may be different delivery streams for different types of files. I look forward to figuring this out as we go along, b/c there’s a big payoff!
For those sites where it doesn’t make sense to set up Continuous Delivery, we’ll have traditional Live Update updates.
Jenkins CI Server
Zach sent me the URL to a Jenkins presentation during our 2-1/2 hour private Hangout. I sent him the URL to a new book I found on Amazon called Integrating PHP Projects with Jenkins.
The presentation is called “Continuous Integration using Jenkins“.
This pdf is also on my site (9Mb), as is the pdf of “The Definitive Guide to Jenkins“.
Slide 13 took me by surprise by using the word “Profit!”. Slid that in there, eh! Read the slides after this one. This presentation is not for you, the site owner and consultant. It’s for other programmers! This is where the value is, and it’s not expected that non-technical people will exploit this technology because it’s just too technical. What I notice is this presentation is a sell job to get programmers to use CI.
At some point, CI will be mainstream. We’re not there yet, but we are on our way. We aren’t waiting for CI to be mainstream, we are all over this thing now.
Using CI means doing Joomla differently. We’re blazing this trail. It’s called Leadership!
The book’s author is described as:
The computer scientist (Diplom-Informatiker) is a co-founder of thePHP.cc and a pioneer in the field of quality assurance in PHP projects. His testing framework, PHPUnit, is a de facto standard.
I can’t get over the comments!
It’s unfortunate, however, that the book is so brief, because much more detail could’ve been provided about the way the tools are best used, especially the meaning of the different metrics included in the various static code analysis tools.
I admit freely that I get frustrated many times by the needless fluff to tech books that appears to be added to books for additional page count. This book has been stripped of almost all fluff, and there needs to be some fluff to provide readers with padded surface to guide them through new information. Readers may benefit from reading the conclusion first.
Rushing a book to market to stake first claim to technical bona fides to bolster a consulting business? Maybe — I can be rather cynical.
To me, this is a nascent area that is growing: CI and PHP. Soon to be CI and Joomla. There is no book on this. We will write this book ourselves. What is different is that our point-of-view is site-owners, and not extension purveyors.
As I said in my “Late Night Thoughts on LaSalleMart” post (with pic of Dustin Hoffman driving on the Golden Gate Bridge):
Surveying the dev@Cloud Jenkins service, I asked myself “What the hell am I doing?”. I’ve had no occassion to get into this stuff ’til now, so what am I doing here? Can this really be the Moneyball of Joomla ecommerce?
Ladies and gentlemen, it really is the Moneyball of Joomla ecommerce. This is where the techies see real value. This is techie stuff created by techies for techies for the express purpose of creating value in the development process. It’s to make things easier, to avoid doing repetitive tasks, to reduce bugs, to increase the quality of the code, to deploy code.
The thing is, it’s a techie thing. The last thing this part of the techie world expects is “users”. But that’s exactly what we are doing. We, site owners and consultants, are driving our Alfa Romeo’s across that great bridge into the golden roadway to RoI. They are not expecting us there, where the shock on the faces of the techies will be clear on their faces. The last thing they expect here are users from the wrong side of the bridge usurping the very technology that creates immense value for their software development process.
Remember who told you about this, before it was fashionable!
Automated testing is a key technology being incorporated into the workings of the Joomla Bug Squad. At the present, this is a somewhat specialized skill…
Specialized, indeed!
There is no glory in testing. There is no glamour in testing. But, there is tremendous value in testing. And extracting that value is what attracts us to testing.
Testing is a major PITA. It’s easier to be casual about it. The problem with casual is that your live site becomes one huge test facility. Live sites cannot be fully simulated in tests, but doing as much testing as possible before the code hits your live site increases your chances of enjoying a smooth running, money-making live site.
As Alan Langford told me, it takes time and effort to set up testing. You have to code so that your code is test-able. The reward is two-fold: quality increases hugely which reduces your operational risk; and, subsequent testing becomes easier as the initial testing set-up is done.
Since testing is not glamourous, is not glorious, is usually thankless, and delays code getting to market, it’s not only glossed over but it’s a skill that only a subset of programmers have. Indeed, a “somewhat specialized skill”.
As of February 2010, a tests folder has been added to the Joomla! SVN download. This folder contains a growing library of unit and system (or functional) tests. The unit tests use PHPUnit and the system tests use PHPUnit and Selenium. The unit tests perform tests primarily on the Joomla! framework. The Selenium system tests actually run Joomla! from a browser and test it as a user would.
http://docs.joomla.org/Running_Automated_Tests_for_Version_1.6
Hmmm, does this mean that such testing was not part of Joomla 1.0 & Joomla 1.5? The implication is that the value of such testing is recognized to exceed its costs only recently. Regardless of when this recognition occurred, we should take the hint at Club Commerce!
I cannot emphasize enough that controlling the software development process offers massive RoI. Open source software gives us the right to control the code. But the huge value resides in the development process. That’s the “Moneyball” aspect — the conventional wisdom is that the value is with the code. But the true value is the development process.
With a testing regimen, we can hire a ton of different programmers for a ton of different projects. The programmers code, and then we run their code through our tests. Code that passes is integrated into our codebase.
We need an explosion of features. So, our software development process must allow us to program an explosion of features. Up-front investment in testing allows us to achieve an explosion of testing.
Testing is a road less travelled, but rich in value. The Jenkins Server is mostly about testing.
I had no idea how deeply Alan Langford, a Founding Member, is involved with testing:
Ground work on the implementation of unit testing has been done by Enno Klasing during the Summer of Code 2007 project and has been perfected by Alan Langford from the Joomla! Development Team.
http://docs.joomla.org/index.php?title=Development_Working_Group&oldid=62385
This is going to make your eyes glaze over: http://permalink.gmane.org/gmane.comp.php.pear.devel/43667
Last week, after we recorded our “The Bob Bloom Show” interview, we chatted for a half hour about LaSalleMart and testing. Alan agreed to do a special one-on-one podcast on testing and LaSalleMart, which we’ll do in March. What prompted this post-show interview was something Alan said off-the-cuff at the recent Toronto Joomla meet-up about testing — which had nothing to do with Club Commerce or LaSalleMart.
Testing is something I did in a former life as a Business Analyst. Use-case testing, mostly, where you dream up phony numbers, manually calculate what the computer is supposed to spit out, then see if the system actually outputs those numbers. Well, we can do “use case” testing in automated tests, saving the hassle of foisting it onto end users.
So, we have a valuable testing skill-set here at Club Commerce. As much as I yearn for all the pet projects that are piling on already to be coded, I am going to devote myself to constructing the test environment. If this takes a couple of months, so be it, because the payoff is massive. We are going to be leaders in testing and Continuous Integration, with the payoff being the ability to accomodate an explosion of features — and getting this quality code to your sites so you can make money with these features.
It’s going to be very interesting, and exciting, to put other extensions through our testing before you install them on your site. This is completely in keeping with the idea that GPL software is Raw Material.
I’m rushing this blog post, because I want to squeeze it in before publishing my already-late February Hangout podcast. So a few observations…
In order to bring an explosion of features to your live site, we need a software development process that accomodates a massive amount of programming.
This software development process, by definition, cannot be like the process other extension purveyors use — because those processes have left us yearning for features.
If the road well travelled has left us frustrated, then the road less travelled is where the pot of gold is.
Most people do not like to travel on the roads less travelled.
My Club Commerce is for site owners and consultants who realize they need to travel on the road less travelled. With 140 memberships available, this is not a mass marketed club.
The “Moneyball” attitude leads us to probe where the value really resides. We identify where the value really resides; and, then we become skilled at these things that build value.
Believe it or not, we’ve concluded that coding is over-rated!
The software development process is where the value is. And, the soul of value is Continuous Integration.
Continuous Integration = test + build.
Testing is a “somewhat specialized skill” — relatively few coders are skilled at testing.
“Build” has led us to the shocking conclusion of abandoning the Joomla installer!
The Fallacy of the One Big Zip file!
We have a surprising competency in testing at Club Commerce. The Toronto Joomla Group, of which we participate, has an unusual competency in testing. So, Club Commerce will be a leader in testing; and, in building ( = Continuous Integration).
So, despite an initial up-front investment of time/effort creating a CI environment, the payoff will be an explosion of features for you.
There are a lot of programmers. Hiring programmers should be easy. We will need money to hire programmers to code.
Club Commerce is a funding model to hire programmers!
There’s an article about GitHub.com called “Lord of the Files” (clever!) at http://m.wired.com/wiredenterprise/2012/02/github/all/1. My favourite quotes: “They weren’t the only developers chafing under that Trusted Gatekeeper model of open source”, and “It’s the startup’s outright hostility toward corporate command-and-control that really sets it apart… yet it’s the most productive software development team he’s ever worked on,”.
My favourite quote from an article about how GitHub.com’s software development, http://scottchacon.com/2011/08/31/github-flow.html is, “we deploy all the time… We don’t really have ‘releases’ because we deploy to production every day – often several times a day”. Yikes! How’s that for “continuous”? No version numbers!
Are You Going To Continuous Integration Fair?
I caught the “Scarborough Fair” scene in The Graduate today, as Dustin Hoffman is driving across the Golden Gate Bridge. With the Academy Awards coming up, Oscar winning movies are de rigour this month.
That long drive over the bridge summed up my feeling today as I dug into Jenkins and builds. A long journey over a very long bridge high above the water. It’s not as if I’m going to make a u-turn, or swerve to the side.
If you think CSS is mind-numbing, then you’re really going to glaze-eye on me about software builds. It is uber-geeky. There is no pretense that a non-techie will use it. It’s a journey into geek-land.
Surveying the dev@Cloud Jenkins service, I asked myself “What the hell am I doing?”. I’ve had no occassion to get into this stuff ’til now, so what am I doing here? Can this really be the Moneyball of Joomla ecommerce?
Ladies and gentlemen, it really is the Moneyball of Joomla ecommerce. This is where the techies see real value. This is techie stuff created by techies for techies for the express purpose of creating value in the development process. It’s to make things easier, to avoid doing repetitive tasks, to reduce bugs, to increase the quality of the code, to deploy code.
The thing is, it’s a techie thing. The last thing this part of the techie world expects is “users”. But that’s exactly what we are doing. We, site owners and consultants, are driving our Alfa Romeo’s across that great bridge into the golden roadway to RoI. They are not expecting us there, where the shock on the faces of the techies will be clear on their faces. The last thing they expect here are users from the wrong side of the bridge usurping the very technology that creates immense value for their software development process.
Like many tools of the trade, these tools are FOSS. The Jenkins Server is licenced under the MIT Licence:
Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the “Software”), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software…
Jenkins is available for free to anyone and everyone. It needs a lot of elbow grease though!
Continuous Integration technology used by lowly “users”, put together by lowly “users”, for the benefit of lowly “users”, is the heart of unlocking RoI for us.
And what I thought as I went travelled through software build technology, having crossed the bridge, was that this is a land that we have to live in. And, by living in it, there really is no border between “extension purveyor” and “user”. We are in the extension business, even though we are “users”. So, from code origination to our individual production websites, it’s one big integrated process.
I thought that the demarcation between “upstream” and “downstream” in the software development process is that point where it crosses into the individual website. Ah, but we are the extension purveyor! So, it’s moot. We are Vertically Integrated. We are engaged in all aspects of the software development process. Origination, testing, building, deploying… there’s no “they”. It’s all “we” now.
You know, it takes my breath away. Controlling the code, which is the underlying premise of the GPL, is just part of it. To truly control the code, you have to hold the software development process in the palm of your hand. That means crossing the bridge into geek-land for Continous Integration, the soul of the software development process.
Github.com does not release software! They deploy continuously, daily:
We don’t really have “releases” because we deploy to production every day – often several times a day. We can do so through our chat room robot, which is the same place our CI results are displayed. We try to make the process of testing and shipping as simple as possible so that every employee feels comfortable doing it.
There are a number of advantages to deploying so regularly. If you deploy every few hours, it’s almost impossible to introduce large numbers of big bugs. Little issues can be introduced, but then they can be fixed and redeployed very quickly. Normally you would have to do a ‘hotfix’ or something outside of the normal process, but it’s simply part of our normal process – there is no difference in the GitHub flow between a hotfix and a very small feature.
Another advantage of deploying all the time is the ability to quickly address issues of all kinds. We can respond to security issues that are brought to our attention or implement small but interesting feature requests incredibly quickly, yet we can use the exact same process to address those changes as we do to handle normal or even large feature development. It’s all the same process and it’s all very simple.
Hotfix is really a Very Small Feature? Well, there is a true understanding where ecommerce profits come from! Profits come from features. Features come from code. That code must actually exist and reside — and work! — on your website. Your focus should be on buying revenue; and, in order for you to buy revenue, you buy features. To buy features, you buy code. Moneyball: You don’t buy players, you should be buying wins. And to buy wins, you need to buy runs. Value is not planning or having star programmers, which are over-valued (Alan will disagree). Value is having real code working for real on your actual website. No technology, no profit! Deploying every day — it’s a culture shock!
The implications! If you deploy everyday, then do you run big massive discrete projects? Wouldn’t we be running a continuous stream of small projects? Wouldn’t we want to run a ton of concurrent small projects? We’d have to find a way to start and finish projects, as we’d be starting and concluding projects all the time.
Theoretically, at least, revenue from the sites under our purview would be growing incrementally, as features were added incrementally every day. A portion of this growing revenue would be, theoretically, re-invested into software development, resulting in more features that create more revenue.
One of the things I learned at tonight’s Toronto Joomla meet-up is that there’s some Continuous Integration skill amongst my Founding Members.
We really are crossing the bridge. No u-turns, no swerving. The technology techies rely on to impart value to their software development process: here we come!
Moneyball -- Where is Value?
Within an hour of publishing my latest podcast, “The Moneyball of Joomla ecommerce“, I received a tweet asking me why anyone would “invest” in my thing without a “solid development plan”.Listening to my “Moneyball” podcast, it’s obvious that I’m not looking at my Club Commerce/LaSalleMart conventionally. This is because convention has left us frustrated, yearning for code!
If we approach our own code development conventionally, then why will we avoid the ailments and pathologies we are seeking to avoid?
Chapter 1, section 1.1 of “Jenkins: The Definitive Guide” opens:
In fact it is a real game changer – when Continuous Integration is introduced into an organization, it radically alters the way teams think about the whole development process… going from a simple scheduled automated build right through to continuous delivery into production.
Circumventing the Joomla installer is a liberating idea. Using “automated builds” to created hundreds of simultaneous versions has a lot of value. Thinking of software development as “upstream” and “downstream” processes opens up a lot of value.
My original idea was to run a club of Tienda clients, so my clients could share the costs of common modifications. The software development process extended to maintaining a custom Distro of Tienda. Since the only one working on this Distro was, essentially, just me, what process did we need? Much time was spent on Live Update, so my clients can effortlessly grab the latest and greatest version.
Well, here we are, at what is the logical conclusion of our journey: that we have to be in the Joomla extension business. We have to create/maintain our own Joomla ecommerce software. This is an entirely different proposition than being in the modifications business.
The last thing I want to do is recreate the problems my clients and I are escaping – principally, vapourware. So, if a “solid development plan” means “tell me when your features will be released”, then I don’t see the point.
Furthermore, our list of features is vast. Practically bottomless. We are starved for features. It’s one thing to be the “mouse on the wheel” for a finite amount of customizations; but, it’s an entirely different thing faced with practically an infinite amount of programming using a ton of programmers for a wide spectrum of site owners and consultants. The question is not “what” and “when”. The real question is “how”.
Researching “how” unearthed surprises. There is a world of opportunity in the “how”. The “how” is where the real value is. As consultants and site owners, we can customize the “how” to suit our purposes. The right to change the code has led us to owning our software development process. Which leads us to Continuous Integration, which is involves testing and building. It is the building that we will blaze a trail.
Jenkins, The Definitive Guide
buy book: Amazon for $35 (no affiliate code in the link)
I have one word for you. One. Word.
{youtube}CsrLHP26zvk{/youtube}
I finally sat down this week, cleared my head, closed my screens, and started reading the PDF.
It didn’t take long to realize that CI = money. For site owners and consultants — really!
Jenkins, the CI server, is FOSS. It’s free! Anyone can download it.
Page 32 in the PDF:
Continuous Integration … is a real game changer… [as] it radically alters
the way teams think about the whole development process.A good Continous Integration infrastructure can:
- streamline the development process right through to deployment;
- help detect and fix bugs faster;
- provide a useful project dashboard for both developers and non-developers;
- ultimately, deliver more real business value to the end user.
There’s more!
In essence, Continuous Integration is about reducing risk by:
- faster feedback — identify and fix integration and regression issues faster, resulting insmoother, quicker delivery, and fewer bugs;
- better visibility for technical and non-technical team members on the state of the project;
- automating the deployment process — get your software into the hands of the testers and the end users faster, more reliably, and with less effort.
CI will be a continuous topic!
