devopsy.kinsta.cloud

Tag: CI/CD

  • Atlassian Adds Pre-Configured Pipelines to Bitbucket CI/CD

    Atlassian Adds Pre-Configured Pipelines to Bitbucket CI/CD

    One of the primary reasons DevOps processes have not been widely adopted across the enterprise is that building pipelines across all the tools required is a painstaking effort. As a result, most pipelines today are constructed using manual pipelines. However, Atlassian has announced it is now making available pre-configured Bitbucket Pipelines that DevOps teams can access via a simple drag-and-drop interface.

    Harpreet Singh, head of product for Bitbucket Cloud at Atlassian, said DevOps teams that rely on the Atlassian Bitbucket continuous integration/continuous deployment (CI/CD) platform will be able to employ a series of pre-configured Bitbucket Pipelines built by Atlassian or one of its third-party partners, rather than having to manually build every pipeline.

    The goal is to make it much easier for DevOps teams to incorporate, for example, a new cloud platform into an existing set of DevOps processes without waiting for someone on the DevOps team to write, test and validate a script, said Singh. IT vendors that have worked with Atlassian to create Bitbucket Pipelines include Google Cloud, Microsoft, Slack and Amazon Web Services (AWS).

    One of the ironies of DevOps is that while CI/CD platforms make it easier to build and deploy applications, constructing the CI/CD platform can be exceedingly complex. A recent survey conducted by Atlassian found DevOps teams rely on 4.3 tools to move code from development into production environments. A full 62 percent of respondents reported they resort to performing manual testing due to insufficient automated test coverage, additional manual processes or a lack of build/deployment pipeline automation.

    While some organizations might have the engineering resources required to build pipelines, he noted, the average IT organization can’t afford to hire operations specialists that have the requisite programming skills required to build pipelines manually.

    Best of all, noted Singh, the pre-configured Bitbucket Pipelines that Atlassian makes available will be maintained and updated by their original authors.

    It’s too early to say to what impact pre-configured pipelines is likely to have on DevOps adoption in the enterprise. But most enterprise IT organizations won’t significantly alter their process until it becomes relatively easy to make that transition. Enterprise IT organizations have relied on administrators to manage IT for decades, and most of those administrators wouldn’t know where to begin if asked to manually construct a pipeline. The few enterprise developers who might be able to build those pipelines are simply to busy writing application code. The result is a paralysis that prevents organizations from modernizing their application development and deployment processes.

    Of course, any meaningful change in the enterprise also involves a chicken-and-egg debate. Lacking skills and tools, enterprise IT organizations are unable to overcome internal inertia, which in turn results in conservative IT organizations preferring to rely on known processes no matter how inefficient they might be. The real challenge facing IT leaders trying to advance DevOps adoption is to remove as many excuses for resisting change whenever and wherever possible, starting with how pipelines are constructed and maintained.

    — Mike Vizard

  • Survey: DevOps Progress Slow, but Steady

    Survey: DevOps Progress Slow, but Steady

    Atlassian has published the results of a survey of 500 IT and software professionals that suggest now is the best and worst of times when it comes to DevOps.

    On the plus side, the survey found that more than half of respondents (57 percent) are encountering fewer bugs and outages after deploying a continuous integration/continuous deployment (CI/CD) platform. Nearly half (47 percent) of those who have adopted a CI/CD platform also report they make changes and receive customer feedback faster. A full 71 percent who have embraced microservices have also discovered it is much easier to test and deploy new software features, according to the survey results.

    However, the survey found three-quarters (75 percent) of development teams face issues with bugs, defects or delays when it’s time to release. A total of 73 percent of software development teams also reported spending 10 percent to 50 percent of their time on updates and upgrades to self-hosted software. On average, according to the survey results, teams rely on 4.3 tools to move code from development into production environments.

    More frustrating, 62 percent of respondents reported they resort to performing manual testing due to insufficient automated test coverage, additional manual processes or a lack of build/deployment pipeline automation. However, among those organizations that have adopted feature flagging to ease management of the application development process, 63 percent report better testing a feature and higher overall rates of software quality.

    The metric IT organizations are employing to measure DevOps success appears a little soft. A full 93 percent of respondents consider customer satisfaction to be the most important DevOps metric, but 60 percent admit it’s difficult to measure customer satisfaction for the features that have been developed.

    Sean Regan, head of growth for software teams at Atlassian, said that while there is clearly much work still to be done, the democratization of DevOps continues unabated. Rather than being limited to a few high IT practitioners, Regan said DevOps processes increasingly are being pushed into the realm of everyday enterprise IT operations. At the same time, many line of business executives are being included within those teams to ensure the software being developed achieves the desired business outcome, noted Regan.

    IT organizations are also starting to apply more engineering principles to the management of IT infrastructure, added Regan. In many cases, IT organizations are discovering a single engineer can be more efficient than 10 systems administrators. However, finding and retaining those engineers is a major challenge. The goal needs to be to create a set of DevOps processes defined by an engineer that are simple enough to be implemented by IT administrators, said Regan.

    Of course, many of those IT administrators today are schooled in less agile ITIL processes. But as ITIL continues to absorb some of the concepts and best practices pioneered by the DevOps community, the divide between engineers and traditional IT administrators should become that much more narrow to bridge.

    — Mike Vizard

  • Deploying into Azure App Service using Azure DevOps CI/CD Pipeline

    Deploying into Azure App Service using Azure DevOps CI/CD Pipeline

    This article demonstrates how to deploy an application into Azure App Service using Azure DevOps (VSTS) continuous integration/continuous delivery (CI/CD) pipeline.

    In this article, you’ll create a sample environment to:

    • New build based on code commit to your Azure DevOps Repo.
    • Automatically deploy your app into Azure.

    Prerequisites:

    • Azure Portal Account, Azure subscription and Azure DevOps (VSTS) account.
    • Azure Resource Group.
    • Create a web app in Azure. Make note of the app service URL—you need it later.

    What is Azure App Service?

    Azure App Service enables you to build and host web apps, mobile backends and RESTful APIs in the programming language of your choice without managing infrastructure. It offers auto-scaling and high availability, supports both Windows and Linux, and enables automated deployments from GitHub, Azure DevOps or any Git repo.

    Creating Resource Group in Azure

    Once you have a subscription in Azure, you need to create a resource group to manage resources in Azure. The best practice is to maintain a separate resource group for each environment (DEV, INT, QA, STAG, PERF, PROD) and follow the proper naming conventions. To create a resource group, select Resource Group from left-side blade, click on +Add, then select Subscription, give a proper name to the resource group and click on Review + Create.

    Creating App Service

    Click on All resources from the left-side blade of the panel and click on Add, then select Web App and give a proper name to your app service. Then select Subscription and select the existing resource group. Keep the remaining option as default. and click on Create.

    Once you have created the app service, click on that app service and go to Overview. There you can identify all the details that belong to this app service, including status, resource group, subscription and URL (please make a note of this; you’ll need it later).

    Creating Service Principal

    When an application needs access to deploy or configure resources through ARM or VSTS in Azure, you’ll need to create a service principal, which is a credential for your application.

    Go to Azure Active Directory -> App registrations -> New application registration, then give a name to the service principle, select application type and give it a URL of your choice. After creating the app registration, go to Settings from that service and make note of application ID,  then go to Keys create a key and copy the secret value. (Note: It doesn’t appear later, so please store it in safe place.)

     

    Create a New Project in VSTS

    The first step is to create an account in Azure DevOps (VSTS), then follow the steps below to start an application deployment. Here I’m taking sample open source java-based code from GitHub repository and importing it to Azure DevOps repo. (You can push your own source code into repo.) It is a simple multi-module Maven project. The application is a very simple online version of Conway’s “Game of Life.”

    To create a new project, click on Create new project, give a proper name to your project and select create. Then go to Repos, click on Import, then select source type, type in the above URL in the Clone URL tab and select Import. The source code will import into your repository.

    We need give service connections to our project, so go to project settings from the bottom of blade in our project home directory and then select Service Connections -> New Service connection -> Azure Resource Manager. Click on “Use the full version of the service connection dialog” from the pop-up, then paste the Application ID into the Service principal client ID tab and the secret key value into the Service principal key tab (which you saved during app registration creation). Then click OK.

    Creating a Continuous Integration (CI) Build

    Go to Pipelines -> Build -> New Build Pipeline, then click on “Use the visual designer.” It will ask source code repo details, so select Azure Repos Git and select Team project, which you created at the start of the project, select Repository and branch name, then click Continue.

    Next, select a template Maven, type in the pipeline name and select Hosted VS2017 for the Agent pool, and click on pom.xml in the Maven POM file. There you can list the goal(s) as Clean Package and select Copy Files. At the contents section please enter **/*.war then go to Publish Artifact: drop, list the artifact name as Gameoflife and keep all remaining options as default values. Then, under Triggers, select Enable continuous integration and give branch filters listed at right, which enables the continuous integration feature. Once a developer commits their changes into master, the CI build will trigger automatically.

    Once the configuration is complete, click on Save and Queue from top of pipeline to trigger a CI build. (Every commit into master will trigger a new build.)

    Creating Continuous Delivery (CD) Pipeline

     Go to Pipelines -> Releases -> New Release Pipeline, then select the template Azure App Service deployment, list the stage name as DEV and click on Add an artifact. Select project and source (build pipeline), then select default version as Latest, click on Add. Cick on Task (below the DEV), select Run on agent and select agent pool as Hosted VS2017, then click on the plus(+) symbol, search for template File Rename and select the .war file from source file and give it the new name ROOT.war.

    In the Display name box, list Azure App Service Deploy. In the Azure subscription field, you need to select a service principal name to authorize the resources. Then choose the App type and App Service name. In the Package or folder selection, select war file and rename it ROOT.war, because for java-based applications we need to deploy our app into a proper directory structure.

    Finally, select the template Azure App service manager and select the Restart option, making sure to select the same subscription and app service name you selected in the Azure app service deploy window. Click on Save, then click on Release -> Create a release -> select artifact build number -> create. Build will then trigger and deploy into the app service.

    Now, your code is successfully deployed into Azure App Service.

    You can access using app service URL from any browser (e.g.,  https://xyz-abc-webjob-01.azurewebsites.net) and you can check whether code is deployed successfully or not using below URL: https://xyz-abc-webjob-01.scm.azurewebsites.net.

    — Srinivas Kudipudi

  • Accelerating MVP Development Performance Through DevOps

    Accelerating MVP Development Performance Through DevOps

    The core concept of minimum viable product (MVP) is to get maximum learning and understanding regarding what customers want about a product. Learning and understanding is a continuous process requiring a development process that is incremental in nature. That makes DevOps a favorite for CIOs and everyone else who dabbles with MVP development.

    How can DevOps help in accelerating MVP development?

    Continuous Updates

    Any MVP is built with assumptions about customer preferences in mind. Developers may have a deep understanding of what customers want, but they have no solid proof. The MVP “tests the waters” and measures the depth of the customer reaction. Developers then can develop and refine the application further, depending on the customer responses.

    Building an MVP that can be easily updated is no easy task, however, especially if the MVP juggles too many APIs that collect data from heavy databases. Traditional application development tactics may not work here. It is here that DevOps makes a difference. Its continuous integration and continuous delivery (CICD) tools ensure that any application or MVP can be easily updated according to dynamically changing scenarios.

    In other words, DevOps can help accelerate MVP development.

    Microservices

    Microservices is a concept in DevOps where the application is broken down into several loosely held parts. For instance, when a social media app is being built, its various components such as a newsfeed, stories, chabot, etc., are built separately as microservices.

    The prime benefit of microservices is that the updating, maintenance and bug-fixing process is simplified and easy to manage. For MVP, this translates into easier editing of feature sets to meet changing customer preferences. Also, it breeds an organizational culture of collaboration in which developers as well as applications have to mingle with each other to perform better. Such a collaborative environment is key to accelerated development of MVP.

    Extensive Automation

    DevOps and automation go hand in hand. In fact, zero-touch automation is deemed to be the future of DevOps. Right from continuous business planning to feedback optimization, there is plenty of scope in MVP for automation.

    Needless to say, automation drives operational agility. It also quickens the pace at which routine tasks are done. DevOps adoption for MVP development means developers can make more features and deployments faster within a short span of time.

    A Scalable Foundation

    Infrastructure as code, or IAC, is a key DevOps practice. It works by configuring servers automatically, especially cloud-based servers. IAC works by creating a single configuration file for all the servers. It is like a single template of configuration that can be cloned easily for several servers.

    As a result, DevOps allows applications to quickly ramp up their server capacity in a flash. The same goes for MVP: When the MVP gets the nod of consent and is mature for advanced development, the same server setup can be used as a foundation for upscaling the resources. Also, the same configuration file can be used to set up as many as servers as you want. What is the result? Cloud servers up and ready to use without loss of time.

    DevOps and MVP Development — A Formidable Combination

    Deploying a MVP is an integral part of the development process. DevOps, with its microservices and IAC approach, can help accelerate the pace at which applications are developed and deployed. Additionally, CI/CD tools ensure wide-scale collaboration among teams.

    Integrating a DevOps culture right from the MVP stage of an application will help in the development of a final product that is bespoke to customer requirements. Even if the customer requirements are different, microservices help to quickly modify them and update the application without significant downtime. To sum it up, DevOps is the perfect approach to accelerate MVP development.

    — Dhaval Sarvaiya

  • What It Really Takes to Build Compliant Apps

    What It Really Takes to Build Compliant Apps

    If you search online for “software compliance,” you’ll be met with a seemingly endless lineup of blog posts, how-tos and explainer articles promising to tell you everything you need to know about writing and deploying software in a compliance-friendly manner.

    Some of those are good resources, especially the ones that delve into meeting specific compliance requirements associated with specific regulatory frameworks. (Articles that make generic recommendations such as “secure your data!” are less helpful, but I digress.)

    In this article, I aim to contribute something new to the conversation about software and compliance, especially as it relates to modern, containerized, microservices-based environments. I’m not going to rehash all of the existing content about compliance best practices. Instead, I’d like to offer a new way of thinking about how you actually build compliant applications—by taking a DevOps approach to compliance.

    What does that mean, exactly? Let me explain.

    Why DevOps Compliance?

    I know, when you hear a term like DevOps compliance, your first thought is likely, “Well, there’s another meaningless buzzword.”

    But when I use that term, I’m thinking about much more than marketing hype. I’m referring to the actual practice of using DevOps processes as the basis for building compliance into your applications.

    I’ll explain what that looks like in a moment. For now, let me explain why the concept of DevOps compliance matters.

    For one, this concept drives home the truth that to create compliant applications, you need to make deliberate design decisions and follow specific processes for implementing them. This is what makes the concept of DevOps compliance, as I’m presenting it here, different from typical recommendations for achieving software compliance. Instead of treating compliance as something that you worry about once your application is written (or as a process that lives in its own silo, if you want to describe it in DevOps-y terms), the innovation behind DevOps compliance is to bake the compliance process into the rest of the software delivery pipeline, ensuring that the software that’s created is secure from the beginning of the development process.

    Implementing DevOps Compliance

    What does DevOps compliance look like in practice? How do you actually bake compliance into a CI/CD pipeline?

    Involving Everyone in Compliance

    For starters, you ensure that everyone who plays a role in software delivery understands what compliance means and which specific compliance requirements affect the software they are building. This is not often the case by default. Typically, compliance is something that your lawyers and security team know about, but not something your developers, software testers or IT Ops team members spend much time studying.

    To do DevOps compliance, that has to change. Your engineers need not become compliance experts, but they need visibility into the specific compliance challenges that they must meet. They must also understand how those challenges change—as they frequently do, because compliance frameworks have a tendency to be updated regularly.

    Tracking Compliance Across the CI/CD Pipeline

    Second, achieving DevOps compliance requires implementing processes that allow you to verify and vet the state of compliance at all stages of the software delivery process. When developers are designing new code, they should be thinking about how that code can be compliant. When the QA team is testing the code, they should verify that it meets compliance goals. And when IT Ops deploys the code, it should monitor it to ensure that it is actually fulfilling compliance needs in production.

    A third key process to implement is auditing across the software delivery life cycle. While the precise reporting and auditing requirements of software vary from one compliance framework to another, it’s a best practice to make sure that you are logging and able to report compliance-related data.

    Auditing

    The problem many organizations run into is that they think about the auditing challenge only when software is in production. To do DevOps compliance, you should be baking auditing into all stages of the CI/CD process by collecting data that demonstrates how you are working to meet compliance goals, and that measures your success in achieving them. This practice ensures that if something goes wrong with compliance, you have full visibility into where the issue originated and how to fix it, which are important considerations for meeting compliance challenges successfully.

    Ideally, you’d never make a compliance mistake, but in reality, you probably will sometimes experience oversights. When they happen, it’s much better if you know exactly what went wrong and can quickly develop a plan for fixing it. That not only helps you avoid repeating the same mistake, but it can also help keep regulatory authorities happy. They tend to be more forgiving of compliance errors if you can show proactively (using your own auditing data) that you know what went wrong, and how you are going to fix it.

    Conclusion

    Compliance is not something that most developers or Ops engineers enjoy thinking about. In fact, it’s something that many of them don’t think about at all, and that’s a problem. But as software-related compliance challenges grow increasingly more complex, and as the consequences of non-compliance grow ever greater (both in terms of regulatory fines and a loss of reputation in the eyes of customers), compliance is something that all participants in the CI/CD pipeline should be supporting. They should be doing so at all stages of the software delivery process, and in a way that maximizes visibility into compliance efforts via a clear auditing trail. That’s what DevOps compliance looks like.

    — Sonya Koptyev

  • CircleCI Automates Configurations Across CI/CD Platform

    CircleCI Automates Configurations Across CI/CD Platform

    CircleCI has unveiled what it describes as the first package manager designed specifically to address configuration tasks involving software delivery automation.

    Matt Wyman, vice president of product for CircleCI, said the Orbs package manager condenses commands, executors and jobs into single, reusable lines of code that automate tasks on the continuous integration/continuous delivery (CI/CD) platform the company provides as a cloud service. The initial set of Orbs being made available by CircleCI are focused on automating more than 25 different cloud deployment scenarios to enable organizations to employ DevOps processes at scale, he said, noting those Orbs can then be validated and shared via an Orbs registry that CircleCI is making available.

    CircleCI is also launching a technology alliance program through which Jfrog, Twistlock, Anchore, Aqua Security, Cypress, Postman, Coveralls, datree, Rollbar and Codacy have committed to building Orbs.

    Wyman said shareable Orbs that require only a few lines of code to develop makes it possible to share configurations across multiple CI/CD workflows. Those Orbs then can be integrated with any number of third-party tools.

    CircleCI is making a case for a CI/CD platform delivered as a managed cloud service that eliminates the need for DevOps teams to set up and manage on their own. Open source CI/CD platforms can be too complex for the average IT organization to set up. Alternatively, CircleCI makes available a version of its CI/CD platform that organizations can deploy behind their own firewall. The CircleCI approach is designed to enable DevOps teams to flexibly create workflows that can be executed sequentially or in parallel.

    There are 12 million builds a month being generated by more than 300,000 developers taking advantage of the CircleCI cloud service to build applications, Wyman said. One of the primary drivers of that success is a cloud service that allows organizations to apply more of their limited resources to developing applications versus managing CI/CD infrastructure, he noted.

    Most IT organizations have yet to standardize on a specific CI/CD platform. Competition between providers of CI/CD platforms has never been more fierce as more enterprise IT organizations embrace DevOps. As DevOps processes continue to mature, it’s also clear that DevOps processes will need to be extended across multiple clouds in addition to on-premises IT environments.

    In general, CI/CD platforms are initially set up by developers who have embraced DevOps processes to accelerate development and deployment of applications without sacrificing quality. The most widely used CI/CD platform is the open source instance of Jenkins. Developers often can adopt Jenkins on their own without requiring anyone to sign off on a purchase order. But as organizations move to scale up their DevOps processes, CircleCI is betting interest in a commercial service that can be easily accessed across an entire enterprise will increase as organizations move to standardize their CI/CD environments.

    In the meantime, pressure to increase the rate at which applications are built and deployed is only going to increase as organizations become more aggressive about digital business process transformation. The issue now isn’t so much whether they will have a CI/CD platform, but rather to what extent—and, in some cases, how many.

    — Mike Vizard

  • CloudBees Further Extends Jenkins CI/CD Reach

    CloudBees Further Extends Jenkins CI/CD Reach

    CloudBees announced it is expanding the scope and reach of its Jenkins open source continuous integration/continuous development (CI/CD) platform into the realms of compliance and serverless computing frameworks.

    Announced at the DevOps World | Jenkins World conference in Nice, France, a new plugin for Jenkins adds support for the AWS Serverless Application Model (SAM) defined by Amazon Web Services (AWS). That model spans AWS Lambda functions, application programming interfaces and Amazon DynamoDB tables and is natively supported by AWS CloudFormation. The AWS SAM plugin supports both classic FreeStyle jobs and Jenkins Pipeline to make it possible to read and deploy serverless applications.

    In effect, CloudBees is making it possible to treat AWS Lambda as a natural extension of any CI/CD pipeline. Longer term, serverless computing frameworks will play a larger role in the cloud-native instance of CloudBees as well.

    In the meantime, CloudBees is also extending its CI/CD platform to address compliance issues that arise from identity management. CloudBees Core is now integrated with the LDAP-based directory Google makes available within its Cloud Identity service. This capability makes it possible to centralize user management policies by using the same Google Cloud Identity or G Suite credentials to connect to CloudBees Core.

    Christina Noren, chief product officer for CloudBees, noted governance and compliance are becoming much bigger issues within best DevOps practices as more responsibility for security continues to shift left toward developers.

    The CloudBees community continues to grow, even as the number of CI/CD rivals continues to expand. At the conference, CloudBees executives revealed the Jenkins community has grown 24 percent in the period Sept. 30, 2017, to September 30, 2018, reaching 192,623 active installations. That number only applies to installations that permit usage information to be transmitted to the Jenkins project, so this number is not representative of the total Jenkins user population. All told, it’s estimated there may be anywhere from 15 million to 23 million developers globally relying on Jenkins. CloudBees also noted the combined number of defined Jenkins Pipeline and other jobs increased during this same annual period, from 10,509,706 million to 20,664,054 million, with Jenkins Pipeline jobs demonstrating growth of 309 percent from last year.

    Noren said one of the primary reasons for that continued success is that unlike other CI/CD platforms that provide a highly opinionated framework accessible only as a cloud framework, the Jenkins environment makes it possible to deploy a more flexible framework on-premises or in a public cloud.

    Of course, there are still millions of developers that have yet to be exposed to any type of CI/CD framework. But as DevOps practices continue to become the primary method through which application development and deployment is increased, it’s now only a matter of time before most developers are working within the context of a CI/CD platform.

    In fact, it’s arguable that those organizations that don’t soon embrace CI/CD platforms will be overwhelmed by rivals capable of updating applications at rates that are increasingly being measured in days and hours versus weeks and months.

    — Mike Vizard

  • VMware Extends DevOps Reach via SaaS Apps

    VMware Extends DevOps Reach via SaaS Apps

    VMware, at the VMworld 2018 conference today, announced it will be delving deeper in the realm of DevOps with the launch of a continuous delivery pipeline dubbed Code Stream.

    In addition, VMware announced Cloud Assembly, a set of declarative tools that enable IT organizations to spin up a cloud in as little as 10 minutes by managing infrastructure as code, and Service Broker, a catalog through which services residing on multiple clouds can be published, governed and secured.

    Milin Desai, vice president and general manager for the Cloud Services Business Unit of VMware, said these offerings extend the reach of VMware’s Cloud Automation Services that are all invoked as software-as-a-service (SaaS) applications.

    VMware also today announced a beta release of Secure State, a set of tools for tracking security alerts across Amazon Web Services (AWS) and Microsoft Azure that also can be used to investigate when changes to those environments were made. Secure Slate is based on the technology the company gained by acquiring CloudCoreo earlier this year. What’s more, VMware is updating the Wavefront by VMware monitoring service to add support for deeper support for containerized workloads running on Pivotal Kubernetes Service (PKS). Wavefront also now supports the Amazon Lambda serverless computing framework made available by Amazon Web Services (AWS).

    Code Stream is designed to track code across multiple platforms and comes with pre-built plug-ins for Wavefront, Harbor, Nexus, Pivotal Kubernetes Service (PKS), Ansible and Slack. VMware is also committed to providing integrations with continuous integration/continuous deployment (CI/CD) platforms such as Jenkins, Desai said.

    VMware has previously made extensive investments in software-defined data centers (SDDCs) based on a layer of management software deployed on top of VMware vSphere. As part of that effort, VMware today announced version 6.7 of VMware vSphere, which adds tools for verifying the state of a virtual machine, and a new Platinum edition of the platform that includes VMware AppDefense, to secure application workloads running on VMware vSphere.

    Beyond the virtual machine level, the scope of VMware’s DevOps portfolio has been limited. By adding a range of DevOps tools that are made available as SaaS applications, VMware now can provide tools spanning just about everything, from cloud orchestration to code delivery, Desai said.

    The expanded push into DevOps comes at a time when VMware is also extending the scope of its alliance with AWS. The company earlier this week announced it has lowered the cost of entry of VMware for AWS by 50 percent for a limited time and is making available a three-node configuration option. Previously, VMware required customers to set up a minimum four-node configuration. VMware will enable IT organizations to configure a three-host software-defined data center (SDDC) for the cost of two hosts.

    The company is further helping to reduce costs by make it possible for IT organizations to also specify the number of processor core counts for Oracle and Microsoft applications running on AWS, along with new options for deploying NSX network virtualization software.

    It’s unclear to what degree VMware will be able to leverage its historic strengths in server virtualization to become a significant force in the realm of DevOps. The acquisition of Wavefront in last year was clearly a significant step in that direction. But the individuals with an IT organization who decide what virtual machines to employ are not necessarily the same individuals selecting DevOps tools. VMware is clearly hoping that as more IT organizations embrace DevOps processes spanning multiple clouds, many more of them will view the company’s growing portfolio of SaaS applications as a natural extension.

    — Mike Vizard

  • From Thought to Leadership

    From Thought to Leadership

    Thought leadership is a term that those of us in the industry hear a lot. A thought leader is a person who has ideas/thoughts that push the edge and brings great ideas to the rest of us. Most vendors want to be seen as thought leaders—and some do, through the agency of rocking individual employees.

    We all benefit from true thought leaders. They dream up new ways to do things (such as DevOps and agile), or find new uses for things (such as adapting agile practices to operations) that, in the long run, we can all benefit from. Good thought leaders (in any space) either look outward and see how what we’re doing today can be used to greater benefit tomorrow, or look inward and make us think about ideas and where we are in accepting them.

    This Isn’t About Talking Heads and Vendors

    The thing is, if you are establishing or attempting to expand DevOps operations in your organization, you are a thought leader. And that’s what I’d like to discuss.

    Those of you who say, “No, not a thought leader; I’m showing how long-established DevOps practices can improve the organization,” are wrong. The key to thought leadership is that you are there, and your audience isn’t. If those long-established DevOps practices were acknowledged in the organization then there wouldn’t be a need for DevOps leaders to establish or expand. Everyone would agree and it would just happen. After sufficient meetings, of course. (The definition of “sufficient” varies by organization and falls somewhere between zero and infinity.)

    In short, a thought leader must simply see what others do not (yet) see. If the audience is internal and resistant, then a DevOps leader is indeed a thought leader for that audience.

    So, What is Required?

    It is true that a big chunk of DevOps is communications. I’m an “automate first, streamline communications after” kind of DevOps person, but acknowledge that the opposite route is also valid. But increased communications are going to be required for long-term DevOps success. Part of that communications is with other managers both in and outside of IT. There is no better time to start than the present, by acting like a thought leader.

    Target the next application/portfolio you think would greatly benefit from DevOps. Sit and refine where you think improvements and/or savings would occur, get the buy-in of line-of-business leaders responsible for the application or portfolio, and go on a PR blitz.

    Thoughts are Great …

    But leadership is better. Be the leader, advocate for what you believe to be right. There are those who will tell you DevOps is inevitable, and it’s not a big deal once there is at least one project in the building doing DevOps. I could not disagree more. Change—any change—doesn’t happen without a champion. If you are in charge of DevOps, yes, take the DevOps Institute Leadership Certification (Disclosure: I have written paid promotional material for this certification. But it’s good material, so I’m mentioning it here anyway), but also look outward. Bring the organization to the table; be visible; be driving.

    But don’t be annoying. Know when to back off, or maybe target a different application first. And know how the existing system reporting and deploying will be mirrored in a full-on DevOps environment, so you can answer important questions such as, “How will we get through test and deploy if we re-target the application?”

    Do I think DevOps is inevitable? No. But I do think it will have a lasting impact on the way we develop and deliver software, even if a particular shop doesn’t claim to be a DevOps shop, deployment automation, test automation, enhanced defect and runtime monitoring, increased communications. These are coming because they’re good ideas. It’s best to have a plan, be a thought leader and get it rolled out so the organization can reap the benefits.

    — Don Macvittie

  • Jump-Start Your Kubernetes Journey with JenkinsX

    Jump-Start Your Kubernetes Journey with JenkinsX

    Containers are very quickly being adopted as the stable way of deploying services. More and more organizations are adopting immutable architecture and containers provide an excellent way to achieve that.

    But along with the stability comes the complexity of deployment, along with managing workload, scaling and updating. That’s in addition to having to create a reliable and repeatable process to continuously build and ship these containers to a production ready state. Kubernetes is one option: It provides features to reliably manage production workloads for your services.

    So now developers have to learn Kubernetes, as well as how to prepare their application for Kubernetes and create the pipeline for continuous integration and continuous deployment (CI/CD). Developers also must determine what is the best approach to get this done and where to start.

    JenkinsX: CI/CD for Kubernetes

    JenkinsX is an open source CI/CD solution for the modern cloud platform for developing and managing applications on Kubernetes. It’s the automation that helps an application move to Kubernetes, deploying various services on Kubernetes to manage an application’s CI/CD journey.

    Developers simply focus on their product and its features and JenkinsX will manage the Kubernetes deployment. It’s opinionated yet flexible, and provides extensive customization. Users can create a Kubernetes cluster using JenkinsX on AWS, Azure, Google or even locally on minikube or minishift. Developers who already have their own Kubernetes cluster and its RBAC (Role Based Access Control) enabled can simply install JenkinsX on top of it.

    JenkinsX provides various templates, and, since it’s open source, more templates are added daily. Developers can do a quickstart with a templated version of spring boot application, a golang project, node, open-liberty, python-http and more. It will create a git repo for a template application and then connect to developer’s github account to push this template to a repo. Also, it sets up the required webhooks to talk to Jenkins, which is installed on Kubernetes as part of the JenkinsX setup.

    JenkinsX also creates namespace environments in Kubernetes. By default, it will create a staging and production environment that can be modified.

    Once changes are made to a templated quickstart application and a pull request is created, the process kicks in and pushes the payload using webhooks to jenkins. The pipeline jobs then kick in to start the build process.

    After the application builds in its own container, the next stage begins to create a docker image and push it to the internal docker registry. Helm charts are generated for the application and stored in the internal hosted chart museum. It is then deployed to a preview environment and developers can view or run tests against the application even before the pull requests are merged.

    As the pull request is reviewed and merged to the master branch, a job kicks in to deploy that application on to the environments. JenkinX implements GitOps, so any and every change is triggered from the github repository. It creates a pull request to the environment repository and adds a change to deploy this application in this environment., validates the pull request and automatically merges it, kick-starting the final deployment stage.

    An environment is mapped to a specific namespace, the application container is then deployed in that namespace, a service is created and all the required mappings are configured. Also, a URL is spit out for developers to hit their application.

    Developers then push their changes, grab a coffee (this step is optional) and few minutes later they get the URL to access the application in that environment.

    That’s the standard workflow. As you might have noticed, JenkinsX is very different from the traditional Jenkins approach. Jenkins provides complete flexibility, whereas JenkinsX provides an opinionated approach. Given everything is in the template repo it creates, you can always modify them to your requirements.

    A Jenkinsfile is created for the pipeline jobs that can be edited to add another stage. Helm charts are created and can be updated if required. Users can disable the default environment it creates the first time and have their own set of persistent or disposable environments.

    This is a great approach toward automating of various different tools we use today to build and deploy our applications on Kubernetes. There are a few features I would love to see added, such as different deployment strategies, support for internal docker registries and maintenance features to clean up obsolete images. That said, JenkinsX removes much of the learning curve and jump-starts your Kubernetes and container journey.

    — Saurav Sen