Application deployments have usually meant deploying a new version of an artifact to Production, with stops along the way in Test, Staging, etc. All the new features and bug fixes become active when you deploy this new version. Although you’ve thoroughly tested the application with automated unit tests, functional tests, load tests, and performance tests, you’ve only reduced the risk of something going wrong in Production. If and when something does go wrong, you may need to rollback to the previous version. But what if the fix wasn’t as dramatic as a rollback? What if you could revert the one mis-behaving feature? Even better, what if you could select which features to activate? In this article I’ll explain how you can control your deployments with feature flags.
DevOps
How to set up a Continuous Delivery Pipeline
Suppose your client or your employer comes to you and says “We need you to help us understand how to set up a continuous delivery pipeline.” They assure you they are committed to the goals and benefits of Continuous Delivery, also known as Continuous Integration/Continuous Deployment (CI/CD):
- The software development teams want to reduce deployment risk.
- They like the idea of frequent small deployments during the workday instead of huge deployments once or twice a year.
- Teams no longer want to dedicate a full weekend to a massive deployment, with all the attendant stresses and risks that brings.
- The business is less tolerant of waiting months before they see even the smallest change; they want a faster time to market.
They have acquired all the tooling, and all they need is your guidance and leadership for how to set up a continuous delivery pipeline.
How would you approach this? What sequence of steps or phases would you use? In this article I’ll present some of my thoughts and suggestions.
Managing and Monitoring Your Java Applications
The Problem
So your team has developed and implemented the five principles of object-oriented design. You’re using Spring Framework as your dependency injection mechanism in your Java applications. You’ve tested the app, it’s been in production for some time now. But how is it doing? Is it healthy? Is it up and running? Oh sure, you can wait for a service desk call to come in, but wouldn’t it be much better if that call came in and you could say “yes, we’re aware of a problem and we’re working on it”? Some form of managing and monitoring your Java applications is moving from “nice to have” toward “essential”.
And when that ticket come in, your first thought. is to see if the app is actually running. You could check log files. You could log in to the app itself, oh wait, your credentials don’t allow you to log in to the production app. Is there a set of support credentials you can use? Where are they?
There has to be a better way.
There is. It’s called Spring Boot Actuator.
Don’t Be Human About Application Deployment
Humans are fallible. To err is human. These are noble assertions when it comes to living the human experience. But when it comes to application deployment, humanity is the weak link in the chain. In this post I’ll explain why and offer arguments in favour of automation.
We like to be in control. We want to make sure a process is done properly, and ultimately our bosses want to know we provided the necessary oversight. But how many manual deployments have you participated in when someone inadvertently omitted a step? Sure, you documented it clearly in the deployment instructions, and reviewed them with your implementers in the days leading up to the big deploy. Even so, that omission caused some sort of delay or worse, cause a data corruption. Now you are still there late Sunday night cleaning up the mess. There has got to be a better way.
But We’re Not Ready to Deploy Our Application!
Does it seem like you’re always waiting for something to be completed before you deploy your application to the User Acceptance Test (UAT) environment? You want to wait for the development team to fix the last few bugs. They have not yet agreed on which transaction manager to use. We’re only a couple days away from finishing feature X. We might have time to get feature Y in. There is no end to the myriad of details to sort out and questions to answer before you deploy.