In Short:
Should I deploy each fix/feature as I make it, or schedule releases for an internal application?
Some Background:
A few months ago I was hired as our IT’s first dedicated developer with the ultimate goal of developing an application to replace a 10 year old internal tool that is used multiple times a day by about 20-30 staff within the office (out of maybe 50-60 in total). The first months were spent getting to know the application as it exists currently: fixing bugs, adding features from the backlog, and integrating web services we want present in version 2.0.
Staff are right there to let me know when they need a little fix/tweak and when something has gone horribly wrong. For the latter case, I obviously squash the bug and deploy the application asap. As we are now ready to begin development of its replacement, my question is around how to handle the small fixes/features that we’ll continue to support over this development cycle.
When I came on as the dedicated developer for this, I was able to implement multiple web-services and additional automations to enhance the application rather quickly, and fixes could be done within a day (as opposed to whenever our head of IT had time to take a break from other duties).
The Problem:
My fear is that the expectation is starting to be created that tweaks can be done and pushed out the same day. Even if I can fix a small bug or add a small feature and deploy within an hour that could be perpetuating the habit of walking up to my desk and staff saying “Can we move x to this side of the page by tomorrow?”
The Question:
Assuming these internal applications can be easily deployed, how often should I deploy them? I’ve tried to implement release versions (for my own sanity) and am considering a once-a-week max (except for breaking bugs) deployment. Is that appropriate? What are the other constraints on release schedule I should consider?
12
In the world of commercial software, release schedules are tied to:
- Development timeline (How long does it take to create each release or patch?)
- Testing and QA timeline (How long does it take to test, qualify, and certify the app as running properly on all the platforms and in all the modes in which it will typically be used; this often includes “integration,” “stress,” and “acceptance” testing, not just unit tests)
- Sales and marketing cycles (How long does it take to create demand for, or acceptance of, the new release?)
- Customer update cycles (How often do customers want new releases? And at what point in their business cycles can they accept new releases/features? Retailers, e.g., lock down all non-urgent upgrades throughout the entire multi-month “Christmas season”)
- Training and support integration (How long does it take to document new features/fixes, train both internal and end-users on them, and get your support team up to speed on the changes?)
Traditionally releases are a Big Deal, for both the software developer and the customers. So release cycles of 1-3 years between “major” releases have been common, with “minor” or “dot” releases every 3-6 months, and emergency patches on an as-needed basis.
Cloud and SaaS (software as a service) shops are the opposite extreme, they often “slipstream” updates without ever telling anyone (maybe their support staff, but not always even then). I know shops that do updates once a week, on a fixed day. Others update as often as several times daily.
You’re a small shop with an internal app, so there’s no real sales/marketing cycle. There doesn’t seem to be any official support or testing/QA function between users and development. Your development cycles seem short, and your deployments easy. So you could iterate as fast as your user community will let you.
Having been in this situation, some suggestions:
- Just because you don’t have an official testing/QA organization doesn’t mean you should avoid testing. Please, please, please have an automated testing suite that you run before every release. This can save you a world of hurt later.
- Just because you can silently “slipstream” new functions or patches doesn’t mean you should. In fact, you should not. Have a real version or release number on EVERY release. This will make tracking down bugs easier. (See e.g. semantic versioning for insight on a structured way to assign release numbers.)
- Have an app web page or “about this app” screen that shows recent version updates. Showing users what is “new and notable” is one of the things fast-updated open source projects have learned helps increase user trust and comfort with the update process.
0
You are asking the wrong question.
»How often should internal applications be deployed« has many implications which are disadvantageous – e.g. if you have a release-cycle – say 1 week – there are perhaps small but important changes, which have to wait 6.x days to the next release.
It would be a better practice to release as often as you have something to release: which could sometimes be once every two days or twice a day; depending on your workflow. If you have features, which aren’t tested enough, you could implement feature-toggles (e.g. configuration values in a DB which de-/activates features). So you could easily roll out to production. And if you realize, that the new feature doesn’t behave the way you wanted, you could roll back as fast as you toggle the featureswitch.
My fear is that the expectation is starting to be created that tweaks can be done and pushed out the same day.
Why should that be a problem?
If you can do the fix, why wait to release it?
Even if I can fix a small bug or add a small feature and deploy within an hour that could be perpetuating the habit of walking up to my desk and staff saying “Can we move x to this side of the page by tomorrow?”
Same question: Why is that a problem?
The only problem you have is communication.
You have to earn credibility: If you say, it could be fixed within 10 Minutes and you push it to production in 10 minutes everything will be fine. But on the other hand, if you say it takes 5 days, you should have so much credibility, that everyone knows, that it takes 5 days. You are in charge, you set the deadlines. And you are responsible to communicate that.
This is oftentimes a painful process for both sides – but in the end: both sides win.
As a professional, you have to communicate, how long something takes. Management doesn’t write software, users do not write software, you write software.
What can I expect to see as I continue in my career in terms of internal applications? Are there best practices for deployment of internal tools? Are they treated any differently?
I can not foresee, where you are going. But in some parts of the industry, what I described vaguely is known as a process called continous deployment and gains more and more attention.
2
I strongly suspect that the answer will be entirely dependent on how painful (or painless) it will be to upgrade 30 people to the newer version.
The easier you make it to upgrade, the better off you will be with a rapid release schedule. The more painful it is, the more you will benefit from a regular release schedule.
It’s completely up to you.
4