Tag: open source tools

  • Open Source Languages and Tools for z/OS

    Open Source Languages and Tools for z/OS

    Open Source Languages and Tools for z/OS

    Empower your developers to use their preferred open source languages. We offer many open source languages and tools—including Git, R and Python—that allow any developer to harness the power of the mainframe without having to spend months learning new skills.

     

    Git

    Git is a version control system (VCS) for tracking changes in computer files and coordinating work on those files among multiple people. It is primarily used for software development, but it can be used to keep track of changes in any files. The z/OS port of git supports automatic tagging and conversion of text files between ISO8859-1 (ASCII) and IBM-1047 (EBCDIC) character encodings.

     

    Bash

    Bash is an sh-compatible shell providing users a command-line interpreter that provides a traditional interface via text window and a script execution capability. It is the default shell on Linux and Mac OS X.

     

    Bison

    Bison is a programming utility for creating parsers. It’s commonly used in both build automation and build automation generation, and converts annotated context-free grammar into a C, C++, or Java parser. Bison is used by PHP, Bash, Ruby, and many other tools.

     

    bzip2

    bzip2 is a data compressor that compresses single files (it is not a file archiver). It typically compresses files to within 10% to 15% of the best available techniques of statistical compressors, while being around twice as fast at compression and six times faster at decompression. This version of bzip2 was not written to exploit z Systems architecture; gzip may work best for these needs.

     

    cURL

    cURL is an open source tool that can transfer data to and from servers by using one of the supported protocols (HTTP, HTTPS, FTP, FTPS, TFTP, DICT, TELNET, LDAP, or FILE). This tool can work without user interaction. cURL functionality includes proxy support, user authentication, FTP upload, HTTP post, SSL connections, cookies, file transfer, resume, and more.

     

    Diffutils

    Diffutils is a package of several programs intended to find differences between files. The diff command, for example, shows exact line differences between two files.

     

    Gzip

    Gzip is a popular data compression/decompression program (our ported tools have been compressed using this utility). This version of Gzip has also been modified to exploit z/OS EDC compression hardware, if present on your system.

     

    libssh2

    libssh2 is a software library that allows developers to use the SSH-2 network protocol in an easy-to-use self-contained package. This package only contains LIBSSH2 libraries intended for use by other programs or utilities.

     

    m4

    M4 is a general-purpose macro processor. Most users require M4 simply as a dependency of Autoconf or Bison, although the language is used in other contexts such as text template re-use, text editing and text-processing applications.

     

    Make

    Make controls the generation of program executables and other non-source files from the program’s source files. Make allows users to build, install and update packages without knowing the process details.

     

    Mktemp

    The mktemp utility takes a given filename template and overwrites a portion of it to create a unique filename. Mktemp also manages the creation of temporary files and directories that allow the user to avoid the cleaning up files that are not needed permanently.

     

    OpenSSL

    OpenSSL is a software library to be used in applications that need to secure communications against eavesdropping or need to ascertain the identity of the party at the other end.

     

    Pkg-Config

    pkg-Config is a programming tool that assists with compiling applications and libraries. It helps you insert the correct compiler options on the command line without the need of hard coding values on where to find glib (or other libraries).

     

    Sed

    sed (stream editor) is a utility for parsing and transforming text. It is typically used for extracting part of a file using pattern matching, or substituting multiple occurrences of a string within a file.

     

    sudo

    sudo is a command-line utility that allows admins to delegate authority, giving certain users the ability to run commands as a super-user or another user, while providing an audit trail of the commands and their arguments.

     

    Unzip

    UnZip is an extraction utility for archives compressed in .zip format. Unzip is also compatible with PKZIP and PKUNZIP utilities for MS-DOS as well as Info-ZIP’s and supports bzip2 compression methods as well.

     

    Vim

    Vim is a highly configurable text editor built to make creating and changing any kind of text very efficient.

     

    Zip

    Zip is a compression and file packaging/archive utility. Zip puts one or more compressed files into a single ZIP archive, along with information about the files.

     

    zlib

    zlib is a general-purpose, lossless data compression library providing in-memory compression and decompression functions, including integrity checks of the uncompressed data.

     

    Download Now   Please link to https://www.rocketsoftware.com/zos-open-source/tools

    Read more about Rocket Support for Open Source Tools   Please link to: https://www.rocketsoftware.com/contact-open-source-tools-zos

    Join the FREE Rocket Open Source Tools Forum Please link to: https://community.rocketsoftware.com/forums/forum-home?CommunityKey=1e694975-142d-4f2d-9b52-0e37e225db41?utag_campaign=ADM&utag_channel=3P&utag_platform=CS&utag_content=OpenAppDevdevopsy.kinsta.cloudmicrosite&utag_location=WW&utag_name=ADM_3P_CS_OpenAppDevdevopsy.kinsta.cloudmicrosite_2020-01_WW

  • Using Open Source for Better DevOps Outcomes

    Using Open Source for Better DevOps Outcomes

    Many insurers have jumped on the DevOps bandwagon in order to improve the efficiency and effectiveness of their systems and systems implementations. Very few insurers, however, spend much time thinking about the open source software community as a way to improve their DevOps approach–and the skills of their developers–and in that regard they’re missing a golden opportunity. In fact, insurers often restrict their developers from updating or contributing to open source libraries because they don’t realize the potential benefits available to them by participating more actively in the open source community.

    A 2016 survey by 451 Group indicated that the more companies used open source solutions in their DevOps portfolios, the more effective the DevOps function was. More specifically, the study reported that among companies with at least 60% of their DevOps portfolio as open source, a full 54% had reached the “fully deployed” DevOps state, with all of their development occurring via DevOps models.

    By comparison, only 30% of the surveyed companies that used less than 60% of open source tools in their DevOps portfolios had reached this state of DevOps adoption. Clearly there’s a link between open source use and DevOps success. Given these results, insurers should focus on the benefits of supporting and encouraging their DevOps groups to embrace the open source community.

    It’s a dated but still persistent view: Participating and contributing to the open source community means developers are giving away their time by creating and contributing intellectual property (IP) that may benefit others outside the organization. However, the truth of the matter is participating DevOps engineers, developers, analysts, etc. are often fixing bugs and making improvements to code libraries other than their own but that can have value for their own DevOps efforts.

    The very definition of open source –software for which the original source code is made freely available and may be redistributed or modified–makes it fertile ground for skills and solutions improvement. Additionally, that process of analyzing and repairing code represents some serious skills development. It’s the kind of development skills that can be difficult to obtain by just working on in-house applications and platforms–which are often proprietary and dated–lacking modern coding techniques.

    Since open source literally means a developer and/or organization has the ability to make the code fit their needs however they see fit–they control their own version of the product that may diverge from the original open source project–the opportunity for DevOps solutions improvement is substantial. Moreover, any DevOps related IP a developer creates and contributes is not lost and is certainly not stolen–the IP can be used directly by the developer and that developer can continue to benefit from the IP of other developers on a gratis basis.

    Utilizing DevOps solutions from the open source community can be both time and cost effective and can be a positive boon to organizations. While some insurers may not knowingly allow open source code in core systems or applications, its use in a DevOps ecosystem is another matter. That’s especially true since DevOps is a newer and less mature IT function that requires new tool, process and solutions development. Leveraging open source solutions can expedite that process. In fact, many of the key DevOps tools used today either are or started as open source solutions for DevOps problems. One would be hard pressed to find a DevOps development stack–from building/developing to monitoring–that didn’t use at least one open source tool as part of the stack.

    Often the fear or apprehension to using open source libraries (for DevOps or anything else) is that anyone could have written it, thus its quality is or could be sub-par. While in some cases this can be true, the same holds true for closed source proprietary software, as many insurers could attest. Simply put, open source tools and libraries are worked on by developers of the exact same caliber–if not the exact same people–who work on closed source proprietary tools and libraries. The only difference is there are often less people involved with proprietary solutions development. And since there are relatively few proprietary DevOps solutions in the marketplace to choose from, open source should be considered a viable channel for DevOps solutions.

    Even if there were more choices for proprietary DevOps solutions, the financial savings involved in combining open source solutions with DevOps can be significant. Importantly, open source solutions for DevOps are particularly useful when the right solution for a problem has yet to emerge, almost a given in a maturing DevOps ecosystem. Rather than rushing out to buy something that promises to fix the problem–or writing something themselves–DevOps developers can find open source solutions and use those to experiment, test and otherwise isolate and identify the true nature of and solution to a DevOps challenge.

    Another reason DevOps groups should avail themselves of open source techniques and tools is the fact that the tools and techniques available for DevOps–proprietary off the shelf and built inhouse–are still not quite there yet. The tools available are almost always missing something, resulting in developers at many organizations spending most of their time–and the organization’s money–trying to develop fully functional solutions from the ground up.

    More often than not, the resulting tool or solution is never as complete or well-built as the open source tool or solution that already exists. Most organizations would be better served tasking their developers with scouring open source libraries, identifying the “best fit” DevOps tools and then spending the time required creating the updates and improvements to the tools that have already been mostly built, saving time and money.

    Finally, there are lots of DevOps staff out there who participate in the open source community–in their spare time anyway, or have done so while working on previous projects. That means hiring DevOps staff with open source experience is a shortcut to potential open source techniques and tools. These are people that can hit the ground running by bringing their open source experiences to bear while they’re getting up to speed on the proprietary work they may be assigned. Considering these benefits, it’s past time for DevOps groups at insurers to dive into the open source waters.

    — Tanner Gibson

  • DevOps Chat: Red Hat Developer Experience in the IBM Era

    DevOps Chat: Red Hat Developer Experience in the IBM Era

    Red Hat Linux is a staple of most enterprise IT organizations’ software diets. Developers and IT leaders all over the world took notice when IBM acquired Red Hat. Will IBM Red Hat change? Will Red Hat continue to operate as it does today or will it be subsumed and disappear into some IBM business unit? Will IBM Red Hat still contribute to projects and tools like Kubernetes, JBoss, Fuse, OpenJDK, Eclipse IDE and many others? All are important questions.

    Brad Micklea, lead of the Developer Program and Tools at IBM, joins DevOps Chat to talk about the future of Red Hat as part of IBM. Brad sends a strong message that Red Hat will remain focused on the developer community and tools for Linux, Kubernetes, Java, DevOps and others.

    Join us as we talk with Brad about the future of Red Hat, DevOps and open source developer tools.

    As usual, the streaming audio is immediately below, followed by the transcript of our conversation.

    Transcript

    Mitch Ashley: Hi, everyone. This is Mitch Ashley with devopsy.kinsta.cloud and you’re listening to another DevOps Chat podcast. Today, I’m joined by Brad Micklea, lead of the Developer Program and Tools Business Unit at Red Hat.

    Uh, Brad, we’re gonna talk about the Red Hat Developer Program experience in kind of this new era, post-era, of acquisition by IBM. Brad, welcome to the DevOps Chat.

    Brad Micklea: Thanks very much for having me. I’ve been a fan of devopsy.kinsta.cloud for quite a while, and so it’s exciting to be able to talk with you today.

    Ashley: Well, thank you. We’re a fan of you and a fan of Red Hat. So let’s start out by having you just introduce yourself, if there are some folks who don’t know who you are. Introduce yourself, a little bit of what you do at Red Hat.

    Micklea: Absolutely. So I run the Developer Tools Program and Evangelism group here at Red Hat. Uh, I’m actually fairly new to Red Hat. I’ve been here about two years. I came into Red Hat via the acquisition of Codenvy, which is a little startup out of California that I was part of, although I’m based in Toronto, Canuck power. Um, so–

    [Crosstalk]

    Ashley: You had to get that in. Good for you [laughs].

    Micklea: I did. I did. I always have to get that in [laughs].

    Ashley: Oh, goodness.

    Micklea: Yeah. So that’s, um you know, so our mandate really is to make–kind of help the whole organization in, you know, reaching out to developers. We have the developer program where developers can come and get great content on topics like Kubernetes and Java and Linux, as well as things like secure programming, DevOps of course, and a number of other things. Uh, we pair it–we kind of marry that with a set of developer-oriented tools that support our projects and our products.

    And evangelism is done as well, of course, in the upstream communities and events and other places, to help developers become aware of what they may not know, which is that Red Hat is not just the Linux company, although, of course, that’s a huge part of what we do. We do so many more things than that in the open source.

    Ashley: Well it seems certainly Red Hat is the model for, you know, a program like that with the developer community, with the user community. And you all have done a fantastic job of expanding that into other areas. Talk a little bit about–it’s more than just the operating system. Tell us about what some of those things are.

    Micklea: Yes. Well, of course, right now, a lot of the buzz is around Kubernetes. And a lot of people don’t realize that Red Hat is actually the second largest contributor and committer to the Kubernetes project.

    Ashley: I did not know that.

    [Crosstalk]

    Micklea: Yeah. Yeah, it’s one of those things where, you know, we’ve been probably the second largest contributor for pretty much the entire history of Kubernetes, but a lot of times it just goes unnoticed. We run SIGs, a number of different things out in the open source for that project and related projects like Tekton, like _____, et cetera. So that’s a huge focus for us right now, and something that is–I’m certainly very passionate about, personally having come, like I said, to Red Hat via a very container-oriented company.

    But beyond that, we have, of course, our middleware portfolio is huge and has been around for, you know, well over a decade with, you know, OpenJDK is, of course, a Red Hat project. We’ve got all of our middleware solutions, whether it be, you know, JBoss or some of our integration platforms like Fuse, our automation platforms.

    So there’s really a ton of different things and it really is something that is exciting about being here for me, because there is a lot of stuff for developers. Although people think of us as a very kind of ops-centric company, we have always had developers at heart and certainly, you know, it’s a company of engineers, really, which is probably why, in some cases we–people don’t know all these things we do because we’re engineers, not marketers [laughs], you know, so.

    Ashley: Write a lot of software you do.

    Micklea: That’s right, exactly.

    Ashley: So I mean, you know, it’s not just Linux. I know you’ve contributed to Java, like IDEs, if I remember right. I think you contributed to Eclipse or something.

    Micklea: Absolutely, absolutely. We were one of the kind of early contributors and continue to contribute to the Eclipse Desktop IDE as well as other Eclipse projects. We’re actually one of the key, I guess, contributors to the Eclipse Cloud Development top-level project and to various projects under that umbrella.

    But also, and this is kind of mind-blowing perhaps for some people who haven’t been tracking where Red Hat has been going over the last several years. We publish a large number of plug-ins for the VS code IDE and–

    Ashley: Microsoft.

    Micklea: Microsoft’s, yeah, Azure DevOps. And, you know, certainly there was a time, maybe what, a decade ago, when the idea of Red Hat and Microsoft hanging out together would have been just inconceivable, but–

    Ashley: There’s been a lot of ret, that’s about it.

    [Laughter]

    Micklea: Yes, that’s right, exactly. But, I mean, those plug-ins have done fantastically well for us. The Java support that you have in VS code is, you know, comes from Red Hat and has, I want to say, a little over 60 million downloads at this point.

    Ashley: Wow.

    Micklea: So it’s incredible stuff, yeah.

    Ashley: Well, it’s amazing how the developer community, you could kind of picture back to the Java days, when you were just Java and that was it and that was the solution to everything. And while Kubernetes has certainly set the world on fire, containers really has, but it’s interesting. What I see is how much the developer communities kind of cross and intersect with each other and work with each other, both at the vendor level, at the company level and just at people developing software. So yeah, you may have a favorite in Microsoft or Google or, you know, in Amazon for a hosting environment or whatever, OpenShift, something like that, but people do a lot more work together it seems like to me. Is that your experience?

    Micklea: Absolutely. And I mean I’m like you, of a certain age, where, like, I remember the people used to just identify themselves as, “I’m a Java developer.”

    [Crosstalk]

    Ashley: “I remember when,” yeah.

    Micklea: Yeah, exactly, right.

    Ashley: “Back in the Java days.”

    [Laughter]

    Micklea: But I mean today, that’s not really the case. Pretty much everybody codes in a couple different languages, at least, sometimes more than that, and has personal projects and the work projects. And so I think it’s just become the norm for developers to kind of pull from many different areas of the community, you know, getting inspiration from different areas and bringing things together in a way that just works for whatever their particular project needed.

    Ashley: You know, it may be a causality, it may be the source of it, but things like DevOps, things like Agile, it’s really changed the way we even think about creating software or the way we form teams, you know, shift left. There’s organizations where they’re trying to sell into a customer base that those people are different now. The security people are part of a dev team and they’re learning development. And in a way, it’s both creating a lot of new business models and operating models on how we create software. It’s also creating question marks maybe and some confusion for some vendors and manufacturers of, “I don’t know if I understand DevOps yet, but I sure got to figure it out because that’s where the world is going.”

    Micklea: Oh, I couldn’t agree more. And I’ll just say, like, thank goodness it is ’cause, um, I certainly–[crosstalk]–don’t miss the way software used to be developed.

    Ashley: Oh, come on, those silos, oh, those were the fun days, yes.

    [Laughter] 

    Micklea: Yeah, but I think it’s interesting, too. Again, as, you know, from our perspective, a lot of what you see in good DevOps practices is similar to what you see in a healthy open source community. You have, you know, people coming to–the whole point or an open source community is that it is open and everybody really is on the same team, and there isn’t so much the straight lines of, “Hey, this group in the community only deals with security, and this group only deals with that.” People do blend. They bring whatever skills they have, whatever experience they’ve got–

    Ashley: ____ to work on, right.

    Micklea: Exactly, that’s right, and I think you see great DevOps teams or–pardon me–great teams that follow DevOps principles, I think you see something very similar, where it isn’t so much like, “Hey, I’m Brad. I’m the ops guys in this DevOps, you know, world. You know, Mitch is the dev guy in the, you know, in this world.” It’s not like that. It’s just, you know, I come and I say, “Hey, I’ve hit this security issue, so let’s not do it this way. Let’s do it this way and we’ll avoid it.” And I think that that’s really what makes it exciting.

    Ashley: Well, you know, you’ve connected those two dots of open source and DevOps in a new way for me, and maybe we really do need to credit open source for creating that and a work team environment that’s evolved now into this DevOps structure. So it makes sense to me. I mean look where open source is coming just in the last ten years, more or less before that. So I’m really curious to–it’s just a rare occasion we get to speak with someone who is really kind of overseeing and leading on such a big community of contributors and users of all the Red Hat technology.

    What does that take? What’s a day in the life of Brad like?

    Micklea: Hmm, uh, it’s interesting. I think one of the things I love about my job, honestly is that I’m a little bit–I get bored easily, um, [laughs], and so this is a job that is never boring. Um, I’ve come from more of an engineering side and product side. So for me, it’s pretty natural to be hopping around, investigating new projects, um, you know, jumping in to get hub repos and looking at pull requests and contributor stats and seeing kind of how is the community and the engagement within different projects changing over time.

    That’s all, you know, just kind of part of kind of who I am and how I work. The part that’s interesting and fun for me is, you know, now hitting more of the program side and the marketing side and, you know, working with folks who are, thankfully, much, much more experienced than I am on my team in this area, and learning from them about, you know, how we can reach out to developers, how we can get our message heard by them, and then helping other folks, both within Red Hat and outside, to understand kind of the best way to speak to developers.

    And I’m, I think, really proud, I guess, of the way that the approach that engineers naturally have to their job, which is one of kind of no nonsense, no hyperbole, just, you know–just the facts please. Let me judge for myself whether this is the greatest thing since sliced bread or whether it’s irrelevant to me.

    And I think that I’m starting to see and I like this, that more and more aspects of marketing, even beyond developer marketing, are waking up to this, this idea of, “We’re the number one,” isn’t the best way to market. It’s really more about saying, “We do this. We do that, and we do the other thing. And if you need those three things, then we might be the best thing for you. And if you don’t need any of those three things, then you probably don’t care.”

    Ashley: I could go on–I could go on a tangent of how many sites, vendor sites I’ve been to and said, “I read your site. I have no idea what you do, but [laughs] nice site.”

    Micklea: That a huge thing, you know, and it’s one of those things that I’ve always been very passionate about when it comes to positioning and content is–and, again, it comes from that engineering background, is I don’t want adverbs. I don’t want adjectives. I just want a description of what it is.

    Ashley: Save the hyperbole.

    Micklea: Yes, save hyperbole. Tell me what it is in plain English, and then I’ll tell you if it’s useful for me.

    Ashley: Mm-hmm. It’s much more of a transparent and kind of honest relationship with the customer, the user, where we’re not trying to flower it up. Yes, we’re trying to–yes, put our light on it, but in a way that they’re gonna consume it, ’cause you’re right. They’re not gonna take the hyperbole and the, you know, we’re the world’s best of everything. We know you’re not, right.

    Micklea: Well, exactly, and I think–

    Ashley: So I’ll be the judge of your technology.

    Micklea: That’s right, and I think if you show people that respect, you know, they reward you. And ultimately as a business even, ’cause, you know, Red Hat is not a, you know, an NGO. We’re a business. We make money.

    Ashley: Mm-hmm.

    Micklea: I’d always rather go to somebody, tell them exactly what they do, and know that either right away they’re gonna say, “Not for me,” and walk away and I lose them. I’m okay with that. I was never gonna win them.

    Ashley: Yeah.

    Micklea: You know, and I’m–so now I can focus on the people who didn’t walk away right away, and now I know that I’ve got a better chance of kind of converting them to my products.

    Ashley: Well, you know, one of the topics I wanted to cover with you is not too long ago the IBM Red Hat merger/acquisition had been completed. And I’m sure you’re not an expert on all things in the merger [laughs] and all things that happened, but what kinds of–if you can share with us, and if not, that’s okay–what kind of things have you heard from the community? What questions are they asking you, now that you’re part of IBM and how have responded? I know you wrote a blog post about some of these things.

    Micklea: Yeah, no, absolutely. And I– let me just start actually by saying that this acquisition personally kind of blew my mind. When I–when I first got the e-mail, it actually was one of those e-mails I had to read two or three times to make sure I was actually reading it properly–

    Ashley: [Laughs] is this, uh, April 1? What happened?

    Micklea: Really, I mean because $34 billion for a company that has nearly no IP. Like, that–when I read that, having been through numerous acquisitions in the past and, you know, having been close enough from an executive level to them that I, you know, was involved in negotiations for how much is this company worth based on how much money does it make, based on how much IP does it have, all those normal questions, I thought, “That’s incredible.” What an incredible kind of proof point of the value and increasing dominance of open source.

    Ashley: And the community. That’s the value.

    Micklea: And the power of the community, exactly. You took the words right out of my mouth. And the power of the community, $34 billion in terms of value of that community.

    Ashley: It’s amazing.

    Micklea: Um, you know, so I think what’s understandably the, you know, initial reaction from many people, you know, both in the community and inside Red Hat and elsewhere, was a bit of skepticism on how this would turn out.

    Ashley: Of course, because you expect–it’s only natural, right.

    Micklea: It’s only natural.

    Ashley: You’ve seen these things happen before. They go well. They did not go well.

    Micklea: Yeah.

    Ashley: You know, what’s gonna happen to us?

    Micklea: That’s right. And, you know, I think it’s easy for people to forget. One of the benefits of having worked in dev tools is I’ve been close to this. IBM has, you know, contributed to open source for a long time now.

    Ashley: Mm-hmm.

    Micklea: That doesn’t make them like Red Hat. I mean Red Hat is quite different and quite unique in the way that we don’t really have any proprietary products. But, you know, at least they are open source aware and have been contributing to open source, and especially, like I said, around dev tools. That’s really been the whole way that they’ve done their dev tools.

    You know, so I am optimistic and kind of in my blog I talked about the fact that the plan is for the developer program of IBM and the developer program of Red Hat to remain separate, and there’s a commitment from both sides to do that.

    And it was funny because going into my very first conversation with my IBM colleagues to try and discuss this, I was honestly quite nervous. I thought you want me to go in there. I don’t know these people, and the first thing I’m gonna say is not very embracing. It’s gonna be, “We’re gonna keep these things separate, guys. I’m sorry. You’re not touching my program.”

    Ashley: Got to go in there swinging, fighting for what’s important, right.

    Micklea: Exactly, and I said–that’s exactly what it was. I said, “You know, this is important to me, so I’ve got to start there.” What amazed me and it was I think a very, very nice thing to see is that from the very beginning it wasn’t even a question. They were like, “Well, oh yeah, of course it’s gonna remain separate.”

    Ashley: Interesting.

    Micklea: Like you need to be separate. You have all that kind of credibility that you’ve developed over 20 years with this community and within open source, and we don’t want to change that. That’s why you’re worth $34 billion.

    Ashley: So now you got my head spinning. Why do you think–how did they come–the folks putting the deal together, how did they come to that conclusion so clearly, where you didn’t have to convince them?

    Micklea: Well, I think that to their credit, there are a lot of smart people in IBM.

    Ashley: Sure.

    Micklea: And, you know, they looked at Kubernetes. They looked at Linux and said–and our Java, and really said, “Hey, you know, these are three core components not just in people’s, you know, datacenters today, but in the way that IT and development will together in the future.” And so, if we go and try and take them, you know, buy it and then grab this stuff and make it proprietary and, you know, do all those things, which, frankly, a lot of people would have expected them to do, there’s nothing stopping everybody from walking away.

    Ashley: Mm-hmm.

    Micklea: There are alternatives and people vote with their feet. So I think that they had the clarity of mind to say, “If we do that, we’re going to be buying a company and then destroying the value of our investment. If, on the other hand, we allow that company to run as it has, and instead give ourselves, IBM, the ability to focus our resources and thinking on parts of this portfolio like OpenShift, like Red Hat Enterprise Linux, so that we can kind of add additional weight and momentum behind them,” and I think that’s really where they see the ongoing value.

    Ashley: It’s awesome that they did that and I think one of the characteristics of something that has a community built around it like this is people make an emotional connection to the brand and to the community, right. They believe in Red Hat. They believe in what this group is developing and the approach that they’re–we’re taking with open source and, you know, being free contributors to it and having that flexibility. And so they don’t want to lose that. So it’s super-smart to keep–I’m not saying there’s anything wrong with the IBM developer program, but it has its characteristics, too, and blending them you–instead of getting the best of both, you might get the worst of them both.

    Micklea: I think that that was exactly the thought, is that if you blend them you’re gonna get actually the worst of both and not the best. And their program has, like you said, a bunch of strengths that ours doesn’t have. Like, we are not able to cover the breadth of topics that they are. We just don’t have the size or expertise to do that.

    Ashley: Mm-hmm.

    Micklea: And so we don’t try, you know. That’s something that’s great for them and they have a killer program, and if you, you know, if you haven’t, Todd Moore wrote a–from IBM–wrote a great blog about the acquisition and kind of his excitement.

    And then from the community perspective, Chris Wright on the Red Hat team also had a wonderful blog on kind of what it means for the community. But you’re 100% correct. The feeling of the community towards Red Hat, and that was one nice thing about the acquisition. Although a lot of people were very vocal about, you know–’cause I was on Hacker News when it happened and trying to respond to some of the–to some of the threads that popped up. You know, people were very vocal about I–you know, this feels like it’s gonna be the end of Red Hat.

    What was–you know, and obviously, I don’t feel that, but I understand where they’re coming from. What was nice though is that it shows the degree to which they cared. You know, there was genuine feelings of sadness in those posts, even though they’re–you know, they’re not–you can’t hear the voice. You could kind of just feel through the post somebody saying, “Oh, this is the end of–if this is the end of Red Hat, that would be a terrible, terrible thing.” And, you know, I don’t think it will be, like I said, but–

    Ashley: Well, you know, it was done well on the front end, this decision about the developer communities. And, you know, of course, just like we were talking about marketing to developers, that transparency, that honesty, the proof’s in the pudding, too, right.

    Micklea: Exactly.

    Ashley: It’s–in the end, that’s what will convince folks of, yep, it is. And maybe it’s a little better, maybe it’s a lot better, maybe it’s the same, but it’s at least got what we love about it. So that’s what you hope happens.

    Micklea: Well exactly, and that was kind of my repeated message. It’s been my repeated message, you know, since then, which is actions speak louder than words. So I can tell you everything is gonna be, you know, the same, as it was and–or sorry, I shouldn’t say that. I believe–I wouldn’t say that because nothing ever remains the same in technology. Even if we hadn’t been acquired by IBM [laughs], things would change.

    But, you know, it’s the core of Red Hat will remain the same. It will still be there. But, you know, people should watch everything we do and, you know, if they see something that they feel isn’t true to that, it should be called out.

    Ashley: Well we’d love to have you on for another episode, maybe a little ways down the road, if there’s some news or just to check in on out in the community and how this unfolded.

    Brad, I want to thank you, Brad Micklea, who is a lead in charge of the, Developer Program at Red Hat. Thank you so much for joining us on the podcast.

    Micklea: Thanks for having me, Mitch. It was a pleasure.

    Ashley: The pleasure’s definitely been mine. I also want to thank you, you, our listeners, for joining us. This is Mitch Ashley with devopsy.kinsta.cloud. You have listened to another DevOps Chat. Be careful out there.

    — Mitchell Ashley

  • Pre-Commit Job Workflow in Azure DevOps

    Pre-Commit Job Workflow in Azure DevOps

    Many organizations use a combination of open so Many organizations use a combination of open source and commercial tools and Azure DevOps (formerly called VSTS) and an application lifecycle management (ALM) tool that includes features such as Azure pipelines. This article talks about how to achieve an end-to-end DevOps setup in Azure

    Pre-requisites:

    1. Subscription
    2. Project created with version control selected
    3. Process template selected (Agile/Scrum)
    4. Code repo–one on VSTS and one on GitHub/cloud GitLab
    5. Build server–Use credits from MSDN subscription
    6. Deploy–Azure subscription from MSDN
    7. Other tools–tools supported by VSTS/Azure DevOps
    • The objective of a pre-commit job is to reduce the risk of complexities, duplications and potential bugs in the code to get deployed directly into production.
    • In usual workflows, the build will be generated on regular intervals and released for testing. However, there is a chance of several code quality issues and building deployment issues.
    • With the help of pre-commit job, we can configure triggers to generate builds for every pull request made by developers. Also, this enables the development team to create pull request releases that deploy your pull request code or pull request builds, which help to detect deployment/release issues before the code changes are merged.
    • Pre-commit deployments also help catch deployment/release issues early in the cycle, maintain better code quality and release with higher confidence.

    Configuring Agile Board in Azure DevOps for Project Management, and Tracking Steps to Do It

    Steps:

    With Azure Boards we can plan, track and discuss work across different teams. With Azure Boards, we can swiftly and simply start tracking tasks, features and bugs of our project.

     

    For every project we have to create on sprint, go to Boards and select Work Items to create a new user story and provide the acceptance criteria. Select Boards and create New Work Items, then under Epic select User Story and click on Task and provide the task description.

    Setting Up Branches, Version Control and Branch Policies

     Steps:

    • Import the code from VCS.
    • Under Repos, create branches such as dev or test.
    • Set up the branches policies to improve code quality.

    Improve Code Quality With Branch Policies

    Branch policies help teams protect their important branches of development. Branch policies enforce a team’s change management standards and code quality.

    Setting up Branch Policies for Review Code

    Code reviews are good practice for the most successful software development projects. We have to configure the minimum number of reviewers to review the code and complete the pull request.

    • The code review done in a pull request is simply to find obvious bugs.
    • Code reviews help protect the team from bad commits or merges and broken builds that hinder team’s productivity.

    The review will help to catch these kind of problems before the merge, protecting our important branches, such as the release branch, from undesirable changes.

    Pre-Commit, Enabling Pull Request

    Steps:

    Workflow to complete the pull request:

    • Create a pull request
    • Complete a pull request

    Benefits of pull request:

    • Peer review
    • Enough testing and better stability
    • Reducing conflicts
    • Continuous delivery
    • Clearer responsibility

    Create a pull request:

    • Pull requests combine the review and merge the code into a single collaborative process.
    • For every bug fix or new feature in a branch, we have to create a new pull request.
    • Add the members of the team to the pull request once the development branch build is completed without issues. Then members can review and vote on your changes.

    Link work items to your pull request:

    Select the Overview tab in Azure DevOps. Select the add link button “+” in the Work Items to relate your current pull request.

     

    Complete Pull Request:

    • The basic policy requires that some reviewers approve the code with no rejections.
    • If Allow users to approve their own changes is not selected, the creator of the pull request can still vote Approve on their pull request, but their vote won’t count toward the Require, least reviewers policy.
    • If any reviewer rejects the changes, the pull request cannot be completed unless the allow users selection is completed, even if some reviewers select Waiting or Reject.
    • To reset code reviewer votes when new changes are pushed to the source branch, check Reset code reviewer votes when there are new changes.

    Nightly CI Build

    Steps:

    Build Triggers:

    • We can configure the build triggers to generate war package for every code commit made to the branch.
    • Under Build select Triggers to enable CI and include master branch.
    • One can enable the build trigger for every commit made to the branch.

    • Configure two builds—one for dev branch and one for master branch.
    • If the developer executes the code, the dev branch build is triggered automatically with help of dev branch polices.
    • Once the dev branch build is completed, reviewers approve the pull request and the master branch build is triggered. Once the build is completed, it moves to the release part.
    • The code quality analysis and unit test/Junit test is configured in the dev branch. The code quality gateways such as code review and find bug have been enabled.

    Continuous Deployment (Release) through Azure Kubernetes Services (AKS)

    Pre-requisites:

    • Any source code management tool such as Git/SVN or Azure Repo
    • Microsoft MSDN account
    • Azure account creation and VSTS/Azure DevOps account creation
    • Dockerfile to be created and placed along with source code in Git
    • YAML file to be created and placed along with source code in Git
    • Kubernetes cluster to be created in Azure portal
    • Docker hub account or Azure Container Registry
    • Build definition–Docker build image

    Docker File Creation for Application to Deploy

    Create the Service Principle to provide the access to the application/Docker image to deploy on Azure Kubernetes services. Select the Deploy to Kubernetes task and make the following configurations:

    • Create new Kubernetes service connection
    • Select the command option for deployment
    • Provide the configuration file location i.e, Deployment.yaml
    • Select the container registry type
    • Select the subscription
    • Select the Replace Tokens task to append the tag number for an image automatically while pushing it to container registry
    • Perform the deployment and view the logs

     

    Test plans:

    Load testing:

    Pipeline History

    Azure Pipelines is used to automatically build and test your code project and make it available to other users. Azure Pipelines integrates CI and CD to continuously test and build your project and ship it to any target server. It provides the full-stack end-to-end flow of CI and CD through various tools integrated as tasks in Azure DevOps.

    Conclusion

    With Azure DevOps, you can set up end-to-end DevOps with tracebility, pre-commit, CI and deployment to Kubernetes.

     

    This article was co-authored by Srinivasa Rao Guntupalli, lead engineer at HCL Technologies Ltd. He works on various DevOps technologies such as Git, maven, Jenkins and cloud technologies including AWS, Azure, Azure DevOps/VSTS.

     

    — Naveen Manchem