One of the requirements for working at Volano has always been the ability to produce a gallant moustache for the month of November.
We would once again like to share the fruits of our labor with the world.
Rod
Don
David
Brandon
I realized last night that even though Volano is a little over four years old, we have a bit of tradition. I think tradition comes from taking a routine and making it significant. I worked for a company once that had beers on Fridays. The department responsible for picking up the beer order was on the corporate calendar. They did not miss a beer:30 during the 14 years (at the time). I enjoyed that tradition and is probably where some of my want for tradition at Volano stems from.
We have drinks and play darts on Friday.
Everyone gets a Herman-Miller chair on their one year anniversary (I didn’t think about attrition when I came up with this one, so we have some newbies sitting in nice chairs now – it just doesn’t seem right to have nice chairs sitting in the corner).
We have purchased an office Christmas present every year.
1. We were just 3 months old and were probably naughty – so no present.
2. Dart Board
3. Mini Bar
4. Desks from IKEA (we were using plastic folding tables previously).
And now it’s the 5 year, I really wanted a couch and area rug for Rod and my office. I want a place for us to sit and discuss the projects we have on the board, a more creative space to architect the solutions and troubleshoot the problems at hand. Make the office a little cozier.
So Rod and I went to NFM and picked up the couch and a coffee table. I think it makes a nice addition to our office.
Volano would like to welcome it’s newest and most valuable employee to the Volano Team. Brandon just recently started with the company, but has already shown signs of super-human intellect and mental prowess. It won’t be long now until he’s signing paychecks and weeding out the rest of the slackers ( your days are numbered Jeremy ).
Ordinarily we would wish a new employee luck, but we already know he’s destined for greatness. Today marks a new chapter in the Volano saga: The Age of Brandon…
As with most processes in application development, release management is a subjective discipline. There are many effective ways to promote new revisions of code into the production environment. The goal is to create a process that is defined, repeatable, and does not adversely affect the production environment when new code is released.
So that is the best-practice theory. With three tiers of testing, an automated build environment, and pre-programmed automated test scripts with great code coverage – going to production will be risk-free. Many organizations need this level of risk-mitigation – therefore the associated expense and timeline is warranted. On the other hand – many organizations need to trade the risk of a less tested build for budget savings and quicker release cycles.
One of Volano’s primary tenets is pragmatism – in this case pragmatism is also known as practicality. We collaborate with stakeholders to determine what level of release management is needed; typically this is ‘finding the happy medium.’ The minimum requirement is two-fold: cross-developer code testing and a full-fledged test system.
Volano’s standard release cycle is very traditional among project based consulting firms (DEV, TEST, LIVE):
New functions and modules are allocated to plan and timelines are set. This becomes the build.
Development (DEV) – development always takes place within a virtual machine. We use VMWare because it works well for both Windows and Mac. Source code is kept in a controlled repository (link).
Quality Assurance (TEST) – as functions and modules become code complete, developer test, and ready for cross-testing – they are promoted to the TEST environment. As the build comes together – someone other than the developer, but usually within our shop – tests the code.
Production (LIVE) – once the build passes TEST it is promoted to LIVE.
Over the years we’ve developed a number of observations about the software release cycle. I’ll share a few:
Regression bugs are the hallmark of poor revision control practices. True regression issues should be infrequent when developers are using source control appropriately.
Releasing to production should be scheduled when possible. Patch releases introduce risk and frequent production releases cause unstable software. Ideally – builds should be released about every three weeks.
An automated deploy process is more reliable than manually built deploy packages.
We’re building a product around custom application assessments. The assessment is a discovery process that will result in an evaluation of best practices along with important application development documentation in the form of a system master document. This will encompass the current application state and we will offer recommendations regarding how best to move forward. These recommendations will be structured as an actionable plan and will include an estimated effort, costs and proposed timeline.
For the release management component of this assessment, we identify the following:
Getting a grip on release management is very important principle of application development. I would say it is second only to source control in terms of IT management.
Source control has been around for a long time. There’s nothing earth-shattering or ground-breaking to say about it here. So, I’m going to borrow from Eric Sink creator of SourceGear, one of the tools we’ve used at Volano:
There are many source control tools, and they are all different. However, regardless of which tool you use, it is likely that your source control tool provides some or all of the following basic features:
The various source control products out there can be categorized by two attributes: Repository Model and Concurrency Model. The Repository Model can be Client-Server or Distributed and the Concurrency Model can be Merge or Lock. Other things you take into consideration include: Is the product open-source or proprietary? And what operating system is it available on?
A lot of developers don’t get the importance of source control or are just too lazy to do it. They give excuses like “but I’m the only one working on the project, so it’s not that important.” BACKUPS ARE NOT SOURCE CONTROL!
We’re building a product around custom application audits. The audit is a discovery process that will result in an assessment of best practices along with important application development documentation in the form of a system master document. This will encompass the current application state and we will offer recommendations regarding how best to move forward. These recommendations will be structured as an actionable plan and will include an estimated effort, costs and proposed timeline.
For the source control component of this audit, we identify the following:
Perhaps it’s my DBA background, but I’ve been very interested in database version control. I’m talking a real product – not just saving the database scripts in one of the standard tools. Red Gate is one of my favorite companies for developer tools. I’ve been using their flagship software, SQL Compare, since 2000 and wouldn’t trade it for anything. Red Gate has introduced SQL Source Control and though I have not tried it yet, it’s on my list to look into.
home about solutions process blog contact us privacy policy sitemap
© 2009-2011 Volano Solutions, LLC - All rights reserved. 1905 Harney Street, Suite 801 • Omaha, NE 68102 • PHONE 402.689.4916
