The guide to DevOps: ‘You build it, you run it’ is a shared responsibility across two teams
The Atlassian Summit is behind us but now’s the perfect time to roll out the interviews with Atlassian executives. We talked to Sean Regan, Head of Product Marketing at Atlassian about everything DevOps, including pillars such as monitoring and automation, the importance of Ops and more.
Transition to DevOps
JAXenter: Could you tell us more about your role at Atlassian and Bitbucket?
Sean Regan: I look after marketing for our software teams since we don’t have any sales people. We partner with the product team to build the right products and then engage the community through marketing, learning, classes, forums, and community. So, my team looks after the growth of the software business teams, which is cloud versions of Jira Software, Bitbucket, and Portfolio for Jira.
JAXenter: There is a lot of DevOps going on. Are you building products with the DevOps approach and mentality?
Sean Regan: It’s definitely intentional. We are running a large cloud-based business. The way we are building and running the products internally is what’s happening to companies all around the world when they create cloud services. It’s made it clear to us where the gaps in the market are, where we have to build our own tools.
Automation is really changing the way the whole organization functions. It’s not just Dev and Ops anymore, it’s the whole company.
A great example of this is when we were building an updated version of Jira, we used feature flagging. Feature flagging is when you reach a subset of your customers – say, 20%, and if it does well then you push it to 30% and then 40%. Some of our engineers hacked Jira to work better with these feature flagging vendors. When I asked the engineers why they hacked it, they said they needed it to work and so do the customers. We ended up building it into the product. It lets the development team and everyone in Jira know how far out a feature is rolled. When we are going through testing, it will update the ticket right there.
That’s a good example of our DevOps transition. This modern environment allows for testing with 10% of people and if something doesn’t work, you roll it back. It creates this new collaboration challenge that we never had in the past.
JAXenter: Two of the main pillars of DevOps are automation and monitoring. How important are they in this context?
Sean Regan: They are critical. Monitoring is especially important. We used that feature flagging example – if I roll out a new feature and we have monitoring on it, if it’s meeting its performance goals, then we will roll it out to more people. Then if it meets a new goal, we roll it out to even more, and so on and so forth. Monitoring can help us push new features out to customers or it can help us say, “Oh, it’s not hitting its goal. Roll it back.”
Automation is also very important in DevOps. If your monitoring isn’t doing a good job, your product goes down, and someone opens up a customer support ticket. If there’s an incident in the IT team, they have to investigate and if there’s a bug, then they ask the software team to build the fix. Ten years ago, these were all separate companies.
What we are trying to do is, if you can connect these teams on the same platform, then the customer feedback can come in and be serviced by the service desk, the incidents can be fixed, and the bug fixes can happen in software. We are all able to communicate on the same ticket. The same ticket can transfer across all teams and when they fix the issue, these teams all see the status change. That automation means the next time a customer support rep gets a question, they know how to fix it. Automation is really changing the way the whole organization functions. It’s not just Dev and Ops anymore, it’s the whole company.
JAXenter: How much automation is too much?
Sean Regan: I wrote a blog post a while back called From too slow to too fast. For a long time, the software industry was criticized that all software projects were late and buggy, especially when we were shipping 15 years ago, once a year. There are teams now doing continuous delivery and they are going so fast that they can’t keep track of what they are doing.
So we are building this new deployment dashboard into Bitbucket where you can see code status: writing, testing, and deployment. Keeping track of all those steps for most tools is manual. Developers don’t want it to be manual. So what we’ve done is we’ve built it into Bitbucket where it automatically updates the issues. As you push code into testing and production, it automatically updates the issues and tells you the status. That helps the entire team understand what’s going on in the same way that feature flagging does.
Automate with care!
There’s a saying that goes, a lie can get halfway around the world before the truth ties its shoes. Well, my version of that saying goes, modern software teams can build and ship a new feature to customers before sales reps can tie their shoes. Because you don’t need the sales person anymore to go knock on doors explain a product, we can just ship a new feature to a customer. It’s going so fast, there is an aspect of being smart with what you automate. How do you make sure the rest of the company can keep up?
I just learned about a new feature today, but I didn’t know it was coming yet. I was blown away. How did this happen? We are moving so fast, that I can’t keep up with all the feature announcements. This is a good problem! I think it’s why group chats have become so popular. You have to start creating ways for people to understand all of this information that is happening around them. Automate with care!
JAXenter: Going back to DevOps, are developers running the show? Or are Ops teams finally taking the lead?
Sean Regan: I think what you are seeing is this idea of you-theory. You build it, you run it. It used to be Devs and then Ops. Even when they came together and partnered, they were still two different teams. What you see with ‘you build it, you run it’ is a shared responsibility across those two teams. Instead of two different teams, its a set of practices. I think the role of Ops and developers is just changing. It’s not a matter of Devs writing better code or Ops keeping it running better.
I’ve been on call, I’ve been an IT admin. When things go down, it’s painful. Your customers and Twitter are saying horrible things. This idea of HugOps emerged. Other people in the software industry will start to send you #HugOps because they know how painful it is to be on that team. I’ve worked on outages that have lasted for three days and people have barely slept. That’s not healthy. What you have to do is create teams and culture that plan for that.
You have to have someone who can come in and help if one of your team members has been too stressed. This culture of safety and empathy is necessary. If you have incidents that are pushing your employees to the limit, it’s not going to be good for anyone on the team.
JAXenter: How can companies go from having a tools-first attitude to an attitude that’s focused on the team?
Sean Regan: Team playbooks are something we are pushing for very hard. There’s always this battle. We try to lead by example and take any of the practices that we have internally about how people work together and open source them. That allows them to help people get to a process and people-first mentality. We can’t go out and tell customers that they are using a tool wrong. But this lets us essentially do that but in a helpful way.
SEE ALSO: GitOps, Jenkins, and Jenkins X
JAXenter: Let’s talk about GitOps. It’s something that everyone knows about, but not everyone fully understands it. How does it make DevOps better? How can it help teams ship better software?
Sean Regan: I think what we are seeing is a rapid evolution in software development tools right now. Obviously Git is at the center; it’s super popular right now. What I think will change over time is, things like Bitbucket and GitHub started off as Git repositories but they are going to become much more than that. Git will still be at the center, but after you write the code and store it on a repository, put it into testing and deploy it, you start to see tools all come together more closely.DevOps
The big difference will be a breaking point in the market where some people may go all in one. So GitLab or Microsoft may go for that suite approach. I think we will focus on an open suite. Our products and partner products will work together, but we won’t try to bundle them or force customers to buy all at once. I think our point of view is, the developers will always choose the best tools. We will have Git at the center, but you can chain tools together based off of the marketplace.
JAXenter: There a lot of developers who believe that containers represent the future of DevOps. Do you think this is the case?
The developers will always choose the best tools. We will have Git at the center, but you can chain tools together based off of the marketplace.
Sean Regan: Fifteen years ago, the slowest part of software development was the loading dock. You had to wait for the truck to deliver the hardware so that Ops could run your software. Containerization frees developers from that process. They can get everything they need to deploy. So I think it just removes one of the human barriers and speeds it up. Serverless will speed that up as well.
There’s a quote from the movie Ferris Bueller’s Day Off: “Life moves pretty fast. If you don’t stop and look around once in a while, you could miss it.” We went from physical servers to VMWare in ten or fifteen years. Then we went to containers and serverless is right behind it. I think containers are helping part of that transition. Companies with a legacy of an IT department have a more historical way of doing things, where you have Devs and you have Ops. They are evolving, which is a little more difficult than a company that can start fresh.
There are a couple of changes we’ve been making in our products to go along with this. One of the things that isn’t addressed very well in the market is code review. Code review prevents incidents, first of all. But if you look at the other players, how they are using Git to organize their work, it’s a social-first platform. So when you follow a repo and you do a code review, you see all the updates from the community. That’s great if you’re the author and you want feedback from the community.
But, if you do code review, it’s hard for you to keep up with all the changes. So what we’ve done at Bitbucket is make code review a single page, and then you can go into that and see the whole history. It makes it a lot faster to do code review. We’ve been seeing customers say it’s made them up to 25% faster. It’s just easier for them to read.
The second change we’ve made is that a lot of Dev tools are moving to the cloud. One of the things we see our customers doing is taking Bitbucket Cloud and Bitbucket Pipelines and running their development tools in the cloud. We think that’s a big transition that is happening. It’s also exciting because it’s another change in the industry.
JAXenter: How do you feel about Microsoft’s acquisition of GitHub?
Sean Regan: I think it’s great that Microsoft is in the game. There’s a ton of worry about, are they going to do the right thing?! I think we have to wait and see but that was a real validation in how important developers are to every business. Software is the key to every business’ success. I’m not surprised to see them move into that space. It’s a very exciting time at Atlassian!