March 14, 2017 at 9:23 pm
Comments posted to this topic are about the item DevOps Isn't Perfect
March 15, 2017 at 2:39 am
I was recently at a place where delivery was not done very well. They put in place a (permanent) DevOps initiative and they have improved and, for more importantly, continue to do so. They would never have achieved this if they weren't committed to the DevOps principle of continuous development.
Gaz
-- Stop your grinnin' and drop your linen...they're everywhere!!!
March 15, 2017 at 3:24 am
I've not yet worked anywhere big enough to have a distinct Operations team sadly. We (development) always write the theme tune, sing the theme tune. This is now changing but slowly enough. I hope to do some of this learning that is spoken of and divest at least a few responsibilities!
March 15, 2017 at 8:52 am
call.copse - Wednesday, March 15, 2017 3:24 AMI've not yet worked anywhere big enough to have a distinct Operations team sadly. We (development) always write the theme tune, sing the theme tune. This is now changing but slowly enough. I hope to do some of this learning that is spoken of and divest at least a few responsibilities!
I consider myself a good database Developer/Admin, but you wouldn't want me messing with your website configuration. Where I work now, we have a dedicated DevOps team. They do things like IIS configuration, domain account administration, instrumentation and automation for deployments, etc. Essentially they perform an assortment of roles and tasks across the enterprise that in some organizations a developer or database admin might have been expected to do occasionally, except a DevOps specialist takes it to the next level professionally. But, of course, everyone in IT is a link in the overall DevOps chain; it's not just a department. Even a small company with a handful of IT employees can apply the principles of DevOps.
"Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho
March 15, 2017 at 9:01 am
Eric M Russell - Wednesday, March 15, 2017 8:52 AMcall.copse - Wednesday, March 15, 2017 3:24 AMI've not yet worked anywhere big enough to have a distinct Operations team sadly. We (development) always write the theme tune, sing the theme tune. This is now changing but slowly enough. I hope to do some of this learning that is spoken of and divest at least a few responsibilities!I consider myself a good database Developer/Admin, but you wouldn't want me messing with your website configuration. Where I work now, we have a dedicated DevOps team. They do things like IIS configuration, domain account administration, instrumentation and automation for deployments, etc. Essentially they perform an assortment of roles and tasks across the enterprise that in some organizations a developer or database admin might have been expected to do occasionally, except a DevOps specialist takes it to the next level professionally. But, of course, everyone in IT is a link in the overall DevOps chain; it's not just a department. Even a small company with a handful of IT employees can apply the principles of DevOps.
This division of work also keeps developers from having unrestricted system access as both control over code and administrative access is often considered a poor situation when considering security.
Gaz
-- Stop your grinnin' and drop your linen...they're everywhere!!!
March 15, 2017 at 1:49 pm
Gary Varga - Wednesday, March 15, 2017 9:01 AMEric M Russell - Wednesday, March 15, 2017 8:52 AMcall.copse - Wednesday, March 15, 2017 3:24 AMI've not yet worked anywhere big enough to have a distinct Operations team sadly. We (development) always write the theme tune, sing the theme tune. This is now changing but slowly enough. I hope to do some of this learning that is spoken of and divest at least a few responsibilities!I consider myself a good database Developer/Admin, but you wouldn't want me messing with your website configuration. Where I work now, we have a dedicated DevOps team. They do things like IIS configuration, domain account administration, instrumentation and automation for deployments, etc. Essentially they perform an assortment of roles and tasks across the enterprise that in some organizations a developer or database admin might have been expected to do occasionally, except a DevOps specialist takes it to the next level professionally. But, of course, everyone in IT is a link in the overall DevOps chain; it's not just a department. Even a small company with a handful of IT employees can apply the principles of DevOps.
This division of work also keeps developers from having unrestricted system access as both control over code and administrative access is often considered a poor situation when considering security.
If you use the right tools (we are using MS Release Manager), you can perform the deployments with a service ID, and not have any human intervention at all, other than having a suitable approver act as the final check on the move to production. We are automating almost every phase of our processes, from backups to acceptance/development from production to executing SQL scripts, to deploying code. I wish we had these tools a long time ago - it would have prevented a number of issues over the years.
March 15, 2017 at 5:27 pm
Eric M Russell - Wednesday, March 15, 2017 8:52 AMI consider myself a good database Developer/Admin, but you wouldn't want me messing with your website configuration. Where I work now, we have a dedicated DevOps team. They do things like IIS configuration, domain account administration, instrumentation and automation for deployments, etc. Essentially they perform an assortment of roles and tasks across the enterprise that in some organizations a developer or database admin might have been expected to do occasionally, except a DevOps specialist takes it to the next level professionally. But, of course, everyone in IT is a link in the overall DevOps chain; it's not just a department. Even a small company with a handful of IT employees can apply the principles of DevOps.
I see this happening as companies look to adopt more of a DevOps mentality. A team focuses, and slowly trains others. Eventually many departments are involved, in their way.
March 16, 2017 at 7:17 am
Isn't a separate DevOps team defeating the whole point? Wasn't the idea to bring people together and not to create a new priesthood?
March 16, 2017 at 7:40 am
David.Poole - Thursday, March 16, 2017 7:17 AMIsn't a separate DevOps team defeating the whole point? Wasn't the idea to bring people together and not to create a new priesthood?
I find that this generally turns out to be the case. I have seen temporary DevOps teams work (pooled from developers and operational support unsurprisingly) when the principles are trying to be first introduced almost as a process POC.
Gaz
-- Stop your grinnin' and drop your linen...they're everywhere!!!
March 16, 2017 at 9:19 am
Yes and no. What seems to work well is a DevOps team coming together, building a POC or working through projects, but being on call as advisors that go to other teams, show what has worked and hasn't, and act as consultants to enable others to start implementing the practices.
Ultimately, the issue is that trust, understanding and confidence are in short supply. It helps to have a group to lean on and guide you through the particulars of your organization. This does help reduce some of the chef problem where each new group gets excited, has to relearn the same skills as others, but perhaps in a different way. Or they don't come up with solutions that work well.
March 18, 2017 at 11:49 am
While I think that orgaizational responsibilities and attitude, and tops down management support are key, I think the role of a well defined DevOps toolchain is commonly under-emphasized. In order to make continuous (small) improvements, you need a controlled and reliable infrastructure to facilitate more frequent code commits and tests. In my casual survey of organizations I think the tooling also plays a big role in shaping attitudes. It's also notable that leaders in the DevOps space (Red Gate included) seem to place a fair emphasis on delivering tools to facilitate the process!
March 20, 2017 at 7:45 am
Tooling definitely matters, though whether this is bespoke (custom) tooling, or purchased tooling is up to you. There are good OSS packages for some things, some good commercial products for others.
Redgate is in the business of selling software, and we hope our products will help you include the database. However, if you want to use other products or tools, feel free. If you want to write your own, I'd discourage that because that becomes a product you need to support, which can be a time sink. I would question the value, but there are plenty of people have have written their own automation tools and they work well for them.
Disclosure: I work for Redgate.
March 21, 2017 at 2:39 pm
I have been reading about DEVOPS now for a bit and I have to say, it sounds like the synergy concept from the 90's or 2000's. It sounds a bit cultist and ZEN and a bunch of other words in that family.
If I understand the basic concepts here, they are that everyone takes responsibility, everyone pitches in, you continually improve your product and your understanding of the product and your methodology.
To me, that does not seem like a new or revolutionary process. It just sounds like good work practices with a snazzy new name. Or am I just not getting it?
March 22, 2017 at 8:29 am
Jim Youmans-439383 - Tuesday, March 21, 2017 2:39 PMI have been reading about DEVOPS now for a bit and I have to say, it sounds like the synergy concept from the 90's or 2000's. It sounds a bit cultist and ZEN and a bunch of other words in that family.If I understand the basic concepts here, they are that everyone takes responsibility, everyone pitches in, you continually improve your product and your understanding of the product and your methodology.
To me, that does not seem like a new or revolutionary process. It just sounds like good work practices with a snazzy new name. Or am I just not getting it?
That's really it. In some sense it breaks down the walls between groups. While some companies took the "everyone" approach, most didn't. I've been a a few that did, a few that didn't. It's easy to pay lip service to continual improvement and joint work. Hard to do.
This in some sense gives a moniker to good practices. In some sense, it pushes for more of a manufacturing process onto software, reducing work in progress, getting better flow, and better mapping your process.
Viewing 14 posts - 1 through 13 (of 13 total)
You must be logged in to reply to this topic. Login to reply