devopsy.kinsta.cloud

Tag: developers

  • IT Services and DevOps: Friends, Not Foes

    IT Services and DevOps: Friends, Not Foes

    Development and operations, aka DevOps, is the marriage between software development and IT operations. The goal of a DevOps team is two-fold: to more quickly make products that are better for customers, and to align more closely with business goals.

    While it sounds pretty great, something doesn’t sit well. What about your service department?

    Service department representatives often become wary at the mention of DevOps. Why? They don’t want to be left behind or lose their seat at the table. Both DevOps and service teams work toward better customer experience, so how do you keep your services relevant with DevOps at the wheel? Will DevOps be the end of IT service management (ITSM)?

    To answer that last question: no, DevOps isn’t going to end your service department. The fundamental goal of having a DevOps team is to improve the alignment between how IT products are created by development and how the operations staff run them once they’re in the real world.

    It’s excellent that DevOps wants to be more efficient, but your services have to be able to keep up. How will you match services to customers’ demands if the DevOps team goes its way? The solution is easier than it sounds, and there are real benefits to the ITSM-DevOps collaboration.

    Creating a Complete Story

    What’s your service department’s main goal—helping your customers? And the primary purpose of DevOps? Are you helping those same customers? One reason a DevOps team exists is to improve customer experience through better alignment across the organization. But, customer experience is your service team’s area of expertise. So, what do you do?

    You hop on the DevOps train and change the destination to the ITSM-DevOps department. DevOps is about breaking down silos. The word says it all. You go from the development team and the operations team to a single team working toward the same goal. The DevOps team is all about the product, and your team is all about the service. But, what if the DevOps team makes products you can’t support with excellent service?

    Once again, the solution is to work together. As you’re breaking down silos, break down another wall—the wall between product and service.

    Bringing ITSM and DevOps Together

    Although ITSM and DevOps serve the same customers, they work very differently. DevOps creates and manages the product with the goal of keeping things running. They are responsible for the product as a whole but usually focus on a few changes or improvements at once. They often work according to Agile methods.

    In ITSM, however, you’re always getting questions about everything. Your work is unpredictable, and while Agile has a lot to offer, you also need guidelines to create more structure in your team’s work. You probably use the Information Technology Infrastructure Library (ITIL) framework, which may seem slow and complicated to your DevOps colleagues.

    How do you go about uniting the two teams?

    Service desks face two main problems when they aren’t that close to DevOps. The combination is paradoxical because DevOps tends to move too fast and too slowly, depending on who is asked and when something is asked.

    Here’s what happens: The DevOps team has its own pace and plans, working on products and features according to the demands of key stakeholders. The service desk is the place where your customers go to get their issues fixed or to gather help with existing features, and when existing features don’t provide as needed.

    The two tracks aren’t always in sync. For instance, DevOps releases new features faster than they did before development and operations teamed up. That means your service agents are receiving questions they can’t answer yet. Plus, the answers are always changing, so they can’t rely on experience.

    Simultaneously, it can feel like you’re waiting forever for DevOps. You may get calls—even recurring calls—about features that need fixing or functionalities that you don’t offer yet. And receiving help from DevOps can sometimes take time because they are currently working on another part of the product.

    Getting in Sync

    Bringing together DevOps and ITSM can seem like a pacing issue. But you don’t need to work on the same things at the same time, and the question isn’t which branch should be in control.

    Collaboration requires communication. DevOps is excellent news for your service desk, provided your service team knows what’s going on. DevOps should always keep ITSM updated on what they’re working on and expected release dates.

    At the same time, service teams should always communicate their needs to DevOps. If customers have issues you can’t solve with the means you have available, make sure DevOps knows and provide them with the information they need to understand what customers are asking for, prioritize projects and provide a better product.

    DevOps shouldn’t be feared. There is no battle for survival between DevOps and ITSM. Everybody will win when they work together.

    — Jeroen Boks

  • OverOps Allies With SonarQube To Improve Application Quality

    OverOps Allies With SonarQube To Improve Application Quality

    OverOps, a provider of tools for dynamically analyzing code at runtime, has partnered with SonarQube, a provider of static analysis tools for source code, to enhance application quality by unifying code analytics.

    Chen Harel, vice president of product for OverOps, said the two companies have collaborated to create a plugin through which DevOps teams can now more easily analyze source code before it gets deployed in a production environment.

    The goal is to equip DevOps teams with the tools required to assure application quality as more responsibility for maintaining applications continues to shift left on to the shoulders of developers, said Harel. In the absence of tools to analyze code, he noted, developers are not going to be able to identify, for example, potential vulnerabilities in source code and errors at run-time.

    The plugin also allows issues identified by OverOps at runtime to be fed back into the SonarQube tools for analyzing source code to identify issues that previously would not have been discovered, he added.

    Specifically, when the OverOps plugin is installed, it automatically creates an event rule for Java code based on new, critical, resurfaced and unique runtime errors. When a quality gate fails a release based on these criteria, users can view the issues directly within their SonarQube dashboard. OverOps then provides a direct link to the event analysis containing the full context behind the error, including the stack trace, variable state and system state.

    As a result, Harel said DevOps teams are going to be able to reproduce an issue much faster, which should result in much shorter times to remediation. Without such tools, DevOps teams can spend weeks reproducing an error that only takes a few minutes to actually fix.

    Harel said with both the OverOps and SonarQube tools included as part of the gates set up within a continuous integration/continuous delivery (CI/CD) platform, it becomes possible to substantially improve the overall quality of the applications being developed. That’s critical because developing applications faster often results in more errors having to be addressed, said Harel.

    There’s a lot of debate these days concerning the degree to which the adoption of DevOps might be increasing the total cost of IT. It’s a lot more expensive to fix an application after it’s deployed in a production environment than it is to address issues as they arise in the application development process. As such, there’s a lot more focus on code analytics to help ensure that DevOps processes are churning out not just more code faster but also higher quality applications.

    Of course, the level of DevOps sophistication tends to vary widely by organization. However, as more gates that address application quality assurance are erected on CI/CD platforms, the better the DevOps outcome will become. The challenge is making sure the DevOps culture being fostered prizes application quality as much as it does how much code is being written and deployed how fast.

    — Mike Vizard

  • What the Best Developers Do to Be Great at Their Jobs

    What the Best Developers Do to Be Great at Their Jobs

    Good developers are in demand—great ones, even more so. With software development employment in the U.S. expected to grow by 21% by 2028, the need for engineers is only going to surge further.

    But this doesn’t mean that the labor landscape will become uncompetitive: Now more than ever, individuals with a passion for software are entering the field, and organizations will only be looking for the best. As the amount of people going into software development goes up—with global numbers expected to reach 27.7 million by 2023—it will become increasingly important to demonstrate your skills and dedication to the profession.

    The gap between a good developer and a great one is bigger than you may think. Here’s what the best developers do to excel at their jobs and lead in their field.

    The Best Software Developers Know How Their Skills Fit Into the Big Picture

    While a good coder handles the responsibilities they have within their role, the best coders make sure they see the big picture. They take the time to understand the foundations of how businesses work, including revenue, profit, bottlenecks and the strategies of departments other than their own. 

    This might mean investing extra time into general business self-education or holding meetings with other departments, but great programmers know it’s worth it in the long run. They recognize the importance of grasping how the cogs of an organization come together to keep things running—and exactly how they fit in.

    By having this 360 view, they can hold influence in areas outside their remit and clearly match the business’ mission to their own work. Valuable coders will use their problem-solving mindset to propose solutions to company-wide problems and put themselves in the shoes of other team members.

    Rest and Relaxation Is Vital for Productivity

    Far from the stereotype of frequently pulling caffeine-fueled all-nighters, the best developers know that, like the powerful systems they work with, they also need some downtime to recharge.

    Great coders challenge the stereotype of having a bad diet and inactive lifestyle and prioritize their own health and well-being. They recognize that as soon as you pass the threshold of 50 hours of work a week, you’re no longer productive. In fact, working too much can be counterproductive, as you’re much more likely to make mistakes.

    Great developers know when to shut down their computer and spend time with their families, do some exercise, spend time in nature and eat a healthy meal. This time to recharge is essential in order to go back to work refreshed and ready to tackle any problems with a clear and rested mind.

    Continuous Learning Is Crucial for Progression

    Ideally, all developers should be making efforts to advance their education in the field they’re in. As a developer, if you stop studying, you’re bound to get stuck at one point or another. The best coders make this a special focus in their lives, and make sure they’re always up to date with the latest developments in the technologies they work with.

    It could be a new coding language, new frameworks or a new technique. Great coders are constantly making a concerted effort to advance their own education. Ultimately, they are always asking “why,” and are unafraid to experiment using their newfound skill.

    Developers can easily find online courses to supplement formal education. Taking part in hackathons is another way to boost extra learning, as well as keeping up with technical blogs and podcasts.

    Great developers also follow other passions outside of coding. For example, the logical nature of software development allows coders to excel at learning other skills, such as languages, playing an instrument, martial arts or even flying a plane. It enables them to exercise the same part of their brain while enjoying something fun and non-work related.

    Personal Projects Show Dedication and Independent Thinking

    Coders know that the best way to learn how to build great products is through practice. Even if the project ultimately fails, building a product will always provide important lessons to apply the next time.

    Side projects that a developer might work on include personal tools, open-source libraries, a startup idea or a freelance project. These personal projects allow programmers to be in the driving seat: They are forced to solve problems independently instead of asking for help, equipping them with skills that might otherwise take longer to gain.

    Engaging in independent work also allows developers to explore and utilize the new languages and frameworks that they gain in their personal education efforts. When developers that have spent time working on their own projects try to prove themselves in the job market, they will stand out against those that have remained largely within the confines of their professional role.

    Ultimately, the vast majority of developers are in the game because they have a passion for building exciting and useful products. This makes it easier to find those who go the extra mile to really hone their existing skills and learn new ones. But, like in any profession, there will always be a certain percentage that remains a cut above the rest. Take a holistic approach to your career in software development with this advice and raise your game, and chances of landing that dream job.

    — Phil Alves

  • The Role of Soft Skills in Building Strong DevOps Leads

    The Role of Soft Skills in Building Strong DevOps Leads

    As an industry, we spend a lot of time talking about the process and technology that make up a good DevOps practice. We have a strong focus on the development, IT operations, QA” and security roles. We debate tools and automation strategies. We wax philosophical about DevOps culture.

    What is either lacking entirely or simply glossed over in that conversation is what I would consider the backbone of any good DevOps team–the people. 

    You might assume by “people” I mean their skills with the technology or their expertise with a certain process. Those two things are important, but all things being equal, the people aspect of DevOps I am referring to is really more simple–or even more basic–than that. It all starts with the culture that is defined by the lead.

    As with any cross-functional discipline, teamwork is essential to the adoption and success of your DevOps practice. At its core, DevOps is about collaboration among people from a variety of teams and departments. It brings together multiple disciplines, people and processes with the common goal of high quality and high efficiency output. DevOps relies so heavily on teamwork that without strong leadership, your DevOps culture and the success of your practice are destined for a rocky road at best.

    A strong DevOps leader will need to bring together people in roles that have either been traditionally siloed or are now being done by fewer people. This is no easy feat, however building trust, earning respect, communicating effectively and motivating everyone toward the common goal is paramount to the success of the DevOps team.

    These traits–trust and respect, communication and the ability to motivate–are not unique to DevOps leads, rather they are the key characteristics that make up any strong leader. By putting them in the context of DevOps, the importance of each in the process and culture is irrefutable. 

    Trust and Respect

    Paul Zak, the founding director of the Center for Neuroeconomics Studies and a professor of economics, psychology and management at Claremont University, led a study to better understand the neuroscience of trust. His team found that the effect of trust on work performance, engagement and loyalty were huge. Respondents indicated that employees with high trust had 106% more energy, were 76% more engaged and 88% said they would recommend their company as a place to work to family and friends. 

    The numbers might not come as a surprise, but how you achieve high trust might. First and foremost, be vulnerable. Do not be afraid to ask for help. This not only exhibits the trust you have in the people on the team, it also demonstrates the sign that you are secure in yourself as a leader. 

    The trust factor for a DevOps lead is multifaceted. The team must trust the lead enough to also trust his/her vision for the process. By showing vulnerability and leaning of the subject matter experts from each discipline for input, you start to build rapport with the team and the process becomes owned by the different functions involved. By asking for help, you invoke the natural tendency to cooperate. That cooperation leads to mutual trust. And by earning trust, you also earn their respect. 

    Communication

    As with any cross-functional team, communication should be viewed as critical an element as your DevOps tools. A successful DevOps lead will be able to understand and speak the languages unique to each discipline. By understanding the nuance and meanings of the words used by the IT operations teams, QA, security and development, the lead can easily help communicate goals, set expectations and establish rules of engagement. Through daily communication, the team will be able to reduce friction and become far more effective as a group. 

    Motivating Toward a Common Goal

    Former Boston Bruins coach Harry Sinden said it best, “Putting on the same jersey doesn’t make a team. You’re still a collection of individuals until you find a common goal.”

    The DevOps lead who motivates the team toward that common goal will find success. But how do you do that? To find out what motivates the people on your team you need to talk to them and get to know them. Involve them in developing the overall strategy. Seek their input and make sure they feel they have ownership of the outcome. 

    Set milestones and celebrate accomplishments. Reward success. Provide feedback and coaching in the moment–both good and bad. 

    The team that feels like they are part of something are no longer a collection of individuals.

    In the end, when you are assessing your DevOps practice and culture, make sure you take a long hard look at the people. They are truly the backbone of any DevOps practice. The need to technical prowess and experience should not be underscored, however, make sure you look for someone who has those skills plus all of the necessary attributes of a true leader. The success of your DevOps practice may depend on it.

    — Sara Faatz

  • What Developers Should Take Away from the Iowa Caucus App Debacle

    What Developers Should Take Away from the Iowa Caucus App Debacle

    In the wake of the recent Iowa caucus, vote-counting software has fallen under suspicion after a smartphone app built by Shadow, Inc., brought chaos and delays to the first 2020 Democratic caucuses. Stopgap measures, such as Nevada officials canceling the application’s use in its upcoming caucus, are not enough to ensure vote tallies the electorate can be comfortable with. What’s needed is to correctly identify and fix the underlying problem. 

    The flaw does not lie with a lack of end-user sophistication, dataset complexity or inappropriate app security. Remember, government officials around the world are transforming urban areas into connected, responsive smart cities. Students are live-streaming interstellar space flights to Mars and Saturn. Uber drivers navigate past traffic jams, while seniors use apps to make time-sensitive healthcare decisions and adjust their retirement portfolios. People of all ages and experience levels do this and more, on the fly, with handheld mobile devices. 

    The real problem lies in the way leadership teams drive software delivery. The Iowa app failed for a number of reasons: It was released with no product testing after a short, two-month development runway conducted under a cloud of secrecy. It was not built to scale. Worse, there was little to no input, transparency or communication among the application’s most important stakeholders—the Shadow management team, the software developers and the end-users, in this case, precinct captains running the Iowa caucuses and party.

    The IT professionals in charge could have avoided these problems by following three simple principles of successful software development: 

    • Collaborate With All Stakeholders: Applications are no longer stand-alone widgets. They are digital experiences. With even the most sophisticated design, experiences that don’t serve their target audience are failures. A development process that prioritizes collaboration with end users can prevent such failures. Feedback from those with a vested interest in the outcome would have quickly raised red flags for developers. In Iowa, collaborating with intended users would have highlighted a need for accessibility training and connectivity issues, since the app was deployed in buildings with high-speed internet along with remote, off-grid locations. 
    • Build to Scale: Every developer knows to build for performance at an order of magnitude larger than you expect. This includes ensuring performance on the widest possible range of handheld devices and phones. From a developer’s perspective, the phone model will impact application performance due to different hardware specs. It’s imperative for designers to build apps that are native, so that all users, devices and performance profiles will function as intended. A useful software solution should reap success, not failure, when more people use an application than initially expected. 
    • Be Transparent: Valid concerns over security risks and election integrity unfortunately led Shadow’s team to prioritize secrecy over transparency. That didn’t work. Problems are not detected and solved when siloed or when small groups of people work on a solution in secret. Proper vetting and testing falls by the wayside. The risk that the app will not be suitable for its intended users increases. The app may have additional, exploitable security vulnerabilities that can only be found when teams ensure proper openness and transparency during the development process. Proper governance and guardrails that protect core data mitigates the security risk for election-based applications (and software in general). There’s little to be gained and much to risk by closing off input and vetting at any point during the full application development cycle. 

    Developers Move From Stressed to Empowered 

    One simple, effective way to solve or avoid these issues is by adopting an enterprise-grade, low-code software development platform. The “low-code” label refers to visual, model-driven software development, which employs an unambiguous visual language throughout the application development lifecycle, enabling nontechnical stakeholders, end users and professional developers to work together. 

    Such a collaborative platform can surface issues with senior leadership before it’s too late. Feedback from citizen developers—that is, not citizens in the voting sense, but rather, non-traditional developers—can capture leadership’s careful attention, precisely because the feedback is from nontechnical users. The right low-code platform would have enabled the Iowa caucus volunteers and stakeholders to collaborate on every step of the process without slowing it down.

    Another benefit of a robust low-code platform is having more people on deck to meet product goals with tight deadlines. Insights from citizen developers with unique backgrounds can also help when testing applications. With suitable governance controls, low-code functionality speeds up a developer’s ability to deliver software without taking away their ability to dive deeply and extend functionality with coding when needed. 

    Market analysts have evaluated the strengths and merits of different low-code platforms. In multi-experience use cases—such as Iowa’s, particularly because the eyes of the world are watching—it’s important to use a low-code platform that enables applications that are truly device native. This allows the software to take advantage of core device capabilities, typically delivering better performance and supporting the interactivity users are familiar with. Additionally, continuity online and offline would address connectivity issues in areas where signals are weak or nonexistent; the data can be properly synced when a signal is available. Lastly, a robust low-code platform provides tools to enable apps to scale automatically, avoiding the coding work required to allow an app originally built for 1,000 people to service 100,000 or a million. 

    An Urgent Role for Software Developers

    When roughly half of all eligible voters sit out general elections, talented developers should not lose sight of the many ways technology can aid and expand civic participation. Eventually, we may live in a world where election-based apps for registered voters are accessible and secure, regardless of the user’s device, age, location, physical ability or educational background. Building in redundant systems of paper-based vote confirmation and other offline systems will add integrity, inspire greater confidence and drive adoption of these innovations.

    What happened in Iowa is, unfortunately, not an isolated case. These complications are endemic to how most leadership teams drive software delivery. Development teams of all types will continue to run into similar issues until their leadership makes transparency, accessibility and scalability a priority by investing in the appropriate resources. Organizations can leverage the strength and impact of fully robust low-code software development platform to that end. 

    Since the introduction of low-code in 2004, platform capabilities have matured at an accelerated rate, moving to widespread adoption for enterprise use. During the same period, elections have increasingly relied on software-driven electronics, leading to consistent issues. Citizens casting ballots is one of the most sacred mechanisms of our republic. Any software used to tally votes must be bulletproof. Truly open and holistic low-code software development platforms can make this happen by proactively bringing people together to make sure software works for those who need it most.

    — Jon Scolamiero

  • Survey Sees Little Progress in Drive to Shift Testing Left

    Survey Sees Little Progress in Drive to Shift Testing Left

    It looks like the drive to shift testing left toward developers to accelerate the development and deployment of applications has stalled. A survey of 102 IT professionals involved in application testing published by Perforce, a provider of testing tools, finds only 18% of organizations test applications solely within their development feature teams. The rest continue to rely on a separate team in one form or another.

    More troubling still, the survey conducted by Gateway Research finds more than half the respondents (56%) are automating less than a quarter of their test cases.

    Eran Kinsbruner, chief evangelist for Perfecto by Perforce, a set of testing tools, said the survey results make it clear that when it comes to automating testing within a DevOps environment there is still a lot of reliance on manual testing. In fact, the survey finds the rate of test automation is less than 50% on average. Almost 40% of teams are automating fewer than a quarter of their test cases, while only 9% automate three-fourths of their test cases, the survey finds.

    On average, only 14% of respondents said they are releasing code daily. Another 39% said they release code weekly, while 46% release code monthly.

    Kinsbruner said it’s clear most organizations are still engaging in a “Big Bang” approach to testing that results in most testing being conducted after large amounts of code has been merged versus being conducted by developers concurrently as code is developed. A total of 66% said they test code after a development project is ready, while 54% said they test when each build is ready. That compares to 43% who test upon each code change and 41% that test at the start of a software sprint.

    A major reason many organizations are not releasing code faster is clearly manual testing. The survey identifies manual testing as the most time-consuming element of the testing process (72%), followed by test environment setup (28%), script creation/maintenance (27%) and test cycle analysis (19%). In terms of biggest challenges organization face, achieving complete test automation (47%) tops the list, followed by test instability/false negatives (44%) and lack of scripting/coding skills (41%).

    In terms of overall priorities, survey respondents placed reducing regression testing time (46%), reducing the number of escaped defects (43%) and automated testing (43%) at the top of the list.

    It may not be possible to automate every part of the testing process, but Kinsbruner said it is clear many more organizations could be automating lower-level testing processes to accelerate application development and deployment. In fact, the survey notes 46% of respondents are looking to invest in test automation in 2020. Among organizations that are using testing tools, two-thirds are using open source software (68%), while 66% are using some type of automation framework.

    Regardless of the approach to testing, Kinsbruner said it’s clear testing teams need more visibility into the DevOps pipeline. Organizations are clearly underestimating how long it takes to thoroughly test an application, so the sooner those teams can see what is being developed the faster they can develop test suites, he said.

    Of course, there are still plenty of development teams that are giving short shrift to testing in the name of achieving delivery deadlines. The trouble with that approach, however, is the end customer all too often winds up being dissatisfied to the point where the application winds up being reject altogether. After the end of the day, nobody really wants more bad code faster.

    — Mike Vizard

  • Multi-Cloud Adoption to Better Enable the Developer Workforce

    Multi-Cloud Adoption to Better Enable the Developer Workforce

    Over the past decade, we started to see a broader shift toward the use of multiple cloud providers by the enterprise. The need to reduce risk, optimize cloud usage, manage costs and the push to open source and cloud vendor-agnostic technologies are providing more options for developers, which will likely lead to an even steeper increase in multi-cloud usage.

    In 2019, we saw the acquisition of Red Hat by IBM, the largest software company acquisition in IT history, to support both cloud and open source software. This acquisition, and others such as Salesforce/Tableau and Google/Looker, suggest that the trend will continue moving forward. In addition to support from mergers and acquisitions, multi-cloud within companies and use by developers will continue to rise.

    Multi-Cloud to Better Enable the Developer Workforce to Keep Up with Competition

    Multi-cloud architecture allows companies to distribute, move and optimize workloads across multiple cloud environments, decreasing the risks and costs associated with running workloads on only a single cloud environment and allowing one to select the best mix of capabilities for the desired use cases. These benefits make the single cloud option far less popular, and results in more interest in multi-cloud deployments.

    This choice is important–to keep up with the competition, digital businesses across the globe need to make better decisions and deliver faster, smarter actions. They must capture and integrate data in real time from wherever it is located, govern these data assets and augment the intelligence of their business through deep analytical insights. These actions must support both the technical and business levels of the enterprise, and developers must be armed with the right tools to enable these capabilities. A multi-cloud strategy ensures that this is possible, and offers the greatest degree of flexibility and choice when it comes to building solutions.

    To further support this shift, it is important to provide developers with the flexibility to choose best-of-breed solutions in order to streamline their processes. Limiting developers to one cloud vendor can restrict them from using the best tool for the job and result in suboptimal cloud deployments. But with a multi-cloud approach, developers can create their own individualized arsenal. Executives, who expect the best from their developers, have to pursue a multi-cloud strategy in order to get the most reliable and fastest results for their business. 

    Industry Insights for Mature DevOps Teams 

    Last year, IBM released research that showed that 85% of the companies surveyed were already multi-cloud adopters. Approximately 39% of those companies have implemented DevOps processes, and 41% have a multi-cloud management strategy. Clearly, multi-cloud is important to the strategy of an organization. 

    As pointed out, in order to be successful with a multi-cloud strategy, one of the key issues for developers to tackle is the creation of strong, automated DevOps processes. These processes must bring structure to a multi-cloud computing ecosystem. According to 2019 research from GitLab, overall DevOps adoption is on the rise, and teams that have successfully implemented a mature DevOps program are seeing major improvements in their workflow. In addition to speed, mature DevOps teams are almost 1.5 times more likely to feel innovative and are three times more likely to discover security vulnerabilities earlier in the pipeline.

    Future of Multi-Cloud Adoption and Impact

    Moving forward, we will see more companies adopt multi-cloud strategies and developers will be among the groups that are most impacted by this approach. For developers, multi-cloud adoption involves matching the business case for certain problem sets to the appropriate cloud providers so the expected ROI can be achieved with the right technology blend. 

    Developers need the right tools to develop, test, support, manage and monitor the deployed solutions consistently across cloud providers. Over time, it may also be necessary to move the solutions from one vendor to another as the requirements, business landscape and cost justifications change. Thus, developers must work within the organization to evaluate and choose the relevant features from each vendor, augment as necessary with external tools and regularly monitor industry trends and capabilities to transition if needed. This is the flexibility that a multi-cloud approach brings, but it must be balanced with the strategy, business and financial needs of the organization.

    The cloud will continue to be a strong technology focus area for enterprises and developers across the globe. Cloud adoption strategies will continue to broaden and shift toward multi-cloud as needed, allowing developers to streamline their processes, select the best tool for the job and create more value for their company as a whole.

    — Nelson Petracek

  • Launchable Aims To Improve Delivery Velocity, With Kohsuke Kawaguchi and Harpreet Singh

    Launchable Aims To Improve Delivery Velocity, With Kohsuke Kawaguchi and Harpreet Singh

    A new company, Launchable, aims to improve your delivery velocity by helping you be much smarter about which tests you run and when. By applying machine learning (ML) and better use of the data output by your software development work, the two co-founders think they can make a meaningful impact on development efforts.

    Sure, you say, lots of developers say they can change the world. But in this case, the co-founders have some very impressive résumés to give you confidence they just may do it. The dynamic duo is none other than Harpreet Singh, former GM of Atlassian BitBucket and VP of Product and Design at CloudBees, and the one and only Kohsuke Kawaguchi, founder of Jenkins and CloudBees Chief Scientist, most recently.

    Wait a second, you may be asking, you’re saying KK from Jenkins/CloudBees has started a new company? Yes, that’s what I am saying. In a podcast that will be available very soon, KK and Harpreet talk with us about Launchable’s why—and why now. Stay tuned for that.

    It’s worth noting that KK has been at CloudBees for 10 years and working on Jenkins for 15 years. In the tech business, that is nearly a lifetime. During our podcast, KK said he felt that with Jenkins being passed to the Continuous Delivery Foundation (CDF), coupled with a healthy group of leaders within the Jenkins community, now was a good time to move on to the next adventure.

    Beyond Jenkins, CloudBees has grown into its own next phase, with lots of exciting developments announced and more coming. The scientist in KK has led him to explore solutions to problems he sees in the way so many companies are doing development. His longtime friendship with Harpreet, dating back to their days at Sun, has energized them both to once again work together and tackle the real problems that development teams are facing.

    What will come out of Launchable? I don’t know. But the company has already attracted some blue-chip VC investment, as well as an impressive list of angels including Sacha Labourey, CEO and founder of CloudBees.

    They (like everyone else, it seems) are hiring development engineers and data scientists. So if working with KK is something that appeals to you, head over to the Launchable site and check out the Careers section.

    I am sure we will be hearing more about Launchable in the days, weeks and months ahead. In the meantime, best of luck to Harpreet and KK, and many thanks for a job well done with Jenkins.

    — Alan Shimel

  • JFrog ConanCenter Extends DevOps Reach to C++

    JFrog ConanCenter Extends DevOps Reach to C++

    JFrog this week announced it has updated ConanCenter, a repository for storing and discovering software packages that can be downloaded for free, to include support for C++ artifacts.

    Jagan Subramanian, vice president of community and partner engineering at JFrog, said ConanCenter provides a repository for the open source Conan package manager that JFrog includes as part of its continuous integration/continuous delivery (CI/CD) platform. By making ConanCenter available free of charge, JFrog is trying to encourage organizations that rely on C++ to build applications to embrace best DevOps practices, Subramanian said.

    JFrog is also making available a free Community Edition of its Artifactory CI/CD platform for C / C++ available for download and later this quarter plans to integrate ConanCenter with other JFrog tools to make it even easier to securely access packages.

    As a general-purpose programming language, C++ has been employed for decades to build applications in IT environments where resources are constrained, such as embedded systems. Subramanian said many organizations that rely on C++ to build those types of applications are experiencing the same pressures to accelerate application development as the rest of their software development colleagues.

    To make it possible to achieve that goal, he said, JFrog is now extending its DevOps portfolio to include support for applications developed using C++ tools. ConanCenter not only provides a means to discover artifacts based on the metadata they generate, but it also provides a list of configuration options and a free binary building service that can be applied across multiple operating systems, platforms and compilers.

    Despite its longevity and the rise of alternative programming languages, C++ continues to fulfill a unique role across a range of vertical industries. There are still plenty of C++ developers are that building some of the most challenging applications to develop. In fact, given the rise of robotics and internet of things (IoT) applications involving autonomous vehicles, interest in using C++ to build new classes of applications is on the rise. The ConanCenter repository promises to make it easier for C++ developers to share artifacts across those diverse projects.

    In terms of adoption of best DevOps practices among organizations that rely on C++, Subramanian said it’s still very early, as most are still at the proof-of-concept stage. However, he said most regularly experience all the pain points that best DevOps practices address, which should drive more organizations to embrace DevOps in the months and years ahead.

    It’s too early to hazard a guess as to how long it might take organizations that rely on C++ to embrace DevOps. Many of them have been relying on waterfall-based processes to build and deploy applications for decades. Nevertheless, just like in other programming environments, the need to build and deploy applications faster requires development teams to embrace change. As always, however, the biggest challenge when it comes to DevOps has little to do with the core technology platforms. Rather, the existing culture of the IT organization always proves to be the biggest hurdle.

    — Mike Vizard

  • How to Use DevOps for Compliance

    How to Use DevOps for Compliance

    Picture this: You’ve been working in an organization’s IT department for a couple of years and tasks have become quite a routine. Some documentation here and there, code reviews, end-user training, routine meetings with the developers and so on. You can do literally everything with your eyes closed.

    Then, all of a sudden, the company is going public and you feel like you’ve been thrown into a different dimension. There are new procedures to follow, endless meetings to attend and a ton of paperwork to be shipped. And don’t forget the new compliance regulations.

    When this happens, do you gamble and quit or stick around and accept the new reality? Is there a truly viable option?

    In comes DevOps.

    DevOps means different things to different companies. Some IT experts consider it a fad while others swear of its significance.

    In many organizations, DevOps combines development and operations. With it comes automation, efficiency and more transparency. With DevOps, changes can be rolled out much quicker.

    DevOps can be the silver bullet for organizations looking to keep up with HIPAA, GDPR, PCI SOX and other industry regulations.

    Here are four strategies for using DevOps for compliance.

    Keep Track of Documentation

    A big part of compliance involves documentation. Yes, boring but critical. With a unified development and operations team, you can merge the documentation processes of those who release changes and those who make them. It’s also easier to get everyone on board when it comes to compliance requirements.

    You can use the newfound synergy between dev and ops to avoid documentation bottlenecks by adopting a unified and trackable version control system. Tools such as Git, wiki pages and internal dashboards can be used to harmonize documentation and version control.

    Make sure everyone is on board by conducting routine training and holding meetings involving both dev and ops personnel.

    Leverage DevOps Automation

    Part of the reason why DevOps has attracted so much attention is the automation it brings.

    With DevOps, time-consuming tasks such as monitoring pull requests, internal audits, access controls, code reviews, failovers and code coverage can be optimized through a transparent, unified and automated system. For instance, you can link all deployments, code review and build results in a single process to streamline audits and daily operations.

    DevOps automation not only helps to streamline internal processes but also in demonstrating that you have met all compliance requirements. Things like access control and failover/recovery processes can stifle your compliance efforts if they are not optimized through automation.

    Streamlining Dev Workflows for Compliance

    Most compliance problems stem from messy development workflows that are not helpful for those keeping track of updates. For instance, an update that is put into production without going through the normal stress tests or internal reviews is not helpful. With multiple teams working on different features during the development stage, it’s easy to overlook small updates that could potentially introduce vulnerabilities.

    DevOps helps to prevent accidental compliance breaches emanating from flawed dev workflows. This is achieved through the integration of stress testing into the development process itself.

    With DevOps, you don’t have to wait until an update is ready for production to stress test it. Working with a dedicated compliance team, you can create a compliance blueprint in the form of a testing and logging system to keep track of code that is still in the production stage way before it goes into production.

    Foster a Compliance Culture

    In a non-DevOps environment, it’s common for different teams or individuals to blame each other, refuse to take responsibility or be out of touch with processes that are not in their job description or assignment. To ensure compliance, a bit of team management is required through communication and culture development.

    DevOps makes this process easier thanks to the improved inter-team dynamics, automated processes and increased transparency. It’s easier to merge the dev and ops teams to help identify potential trouble spots and ways of resolving them. The operations staff will not blame the developers when a disaster occurs if they were part of the entire process and vice versa.

    Effective teams always take responsibility instead of looking for a fall guy or starting finger-pointing when something is amiss. Inculcate a culture of compliance in your teams by ensuring that they are all aware of what is required of them and their shared responsibilities.

    From the above, it is clear that DevOps can be the only thing you need to ensure compliance in your organization. However, adopting multiple recommendations at a go can be challenging. Therefore, take it one step at a time and use available tools, such as Git, to implement some of these processes.

    — Ken Lynch