Dimensional Data

A lot of DevOps professionals might feel confident they’ve got a lock on their DevOps role. They don’t need anyone else chiming in on how to update a software feature or plan a new product. Other DevOps pros want to focus on learning new programming languages or figuring out how best to use machine learning. They think they don’t have time for so-called soft skills like communication and collaboration. At its heart, DevOps is collaboration. It’s a team sport. Of course, staying sharp with hard skills like machine learning, new programming languages, and other cutting-edge technology is fantastic, but don’t ignore soft skills. Enabling teamwork is a cornerstone of DevOps. Making this cultural shift means teammates are all pulling in the same direction. It means more, and more diverse, input leads to better, well-rounded products and software. And it also means career development. Here’s a look at just a few ways a culture of collaboration can benefit a DevOps team, software development and deployment, and DevOps professionals’ careers. Boosting DevOps professionals’ careers It’s clear that companies are increasingly dependent on DevOps professionals who are able to not only work with various teams, but who also are able to clearly communicate with colleagues in other departments, like finance and marketing. The 2021 Global DevSecOps Survey reported that IT professionals working in development, security, and operations all said they need better communication and collaboration skills for their future careers. And nearly 23% said these soft skills will give the biggest boost to their careers. Being able to work across departments, clearly communicate needs and ideas, and work together to innovate better products makes a tech person more valuable to the overall company, leading to management roles and higher salaries. Using the buddy system to iterate faster The bedrock of a DevOps culture is collaboration and joint responsibility. And for good reason, because better cooperation leads to more, and more efficient, continuous, iterative development and feature deployment. Cooperation makes a DevOps team more agile so it can adapt to changes in projects and workloads. With traditional application development, managers, developers, security professionals, and those on the operations team generally work in silos. They don’t communicate readily or well. They don’t work together on projects or share documentation and knowledge. With DevOps, though, those silos begin to be broken down. And by joining forces, teammates can pool efforts to assess problems, envision solutions, and create and deploy high-quality applications from a single end-to-end application. Breaking down those silos fosters better decision-making and creativity, and increases information and resource sharing. Creating better products By creating partnerships, DevOps teams are able to more quickly adjust to changing market needs and take on new competitors. Sharing data, and the workload, across disparate teams also empowers them to find out what customers need, what delights them, and the features that need to be created. More input from people with different perspectives and different backgrounds means a company will get software with features that speak to a wider range of users. All of this leads to better products, and that leads to a stronger business. Pulling different business teams together Fostering cooperation isn’t just for DevOps team members. A truly collaborative culture also should include colleagues in different parts of the company. Members of the security team, marketing, finance, […]

Being part of the GitLab collective is an opportunity to learn first hand about the challenges the community using the DevOps Platform is facing. As a Collective Member logging between 2-3 times a week in StackOverflow reading the questions and discussion posted about GitLab and manually sorting them by ‘Recent Activity’, ‘Trending’ and using Dates, I asked myself: how can we leverage this wealth of data and discover feedback, while finding the most frequent topics where the community has questions? This would be an opportunity to get a quick overview of topics where the community regularly needs help; this would also make it easier for us to create relevant content for them. Manually sorting and extracting the text of each question wouldn’t be sustainable, so creating an automated way would be the most efficient way to proceed. Experimenting with data-oriented content creation Finding out what the community is working on, and what they need help with while using GitLab, can help us to create better educational content that could expand their understanding of GitLab. To achieve this goal, the solution I created after a few iterations is depicted below: Where the Bill Of Materials consists mainly of: GitLab DevOps Platform Stackoverflow API Kubernetes Cluster Open Source Python libraries: scikit-learn (TF-IDF) Streamlit (front-end) Spacy I leveraged the GitLab DevOps Platform to organize the projects using groups: The Loader project pulls questions about GitLab from the StackOverflow API, pre-processes the text and makes it usable for a second project: a Visualizer to create customized dashboards. The automated process executed using the DevOps Platform is outlined below: Pull data from StackOverflow API Preprocess the response extracting relevant fields from returned JSON Build a corpus and calculate TF-IDF Scan for security vulnerabilities Review Application and display its resulting dashboards using Streamlit Deploy the built application to a Kubernetes cluster Loader and Visualizer projects have their own codebase and pipelines, which is helpful if different teams need to work separately on them. However, one project can require the other, which raises the need for cross-project automation. This scenario means a multi-project pipeline is useful to automate the whole process. The multi-project pipeline enables use cases such as: As an NLP Developer I want to work on the NLP Pipeline in the Loader Project and automatically trigger the creation of a new visualization As a Streamlit Developer I want to work independently in the buttons and data visualization without touching any NLP Pipeline backend The outlined process above is automatically run defining the steps in a multi-project pipeline sharing artifact: Finding the most frequently occurring words The Feature Engineering step will help me to analyze the text in the whole dataset of GitLab questions. Using a simple yet powerful technique – TF-IDF – we aim to find the most relevant terms utilized by the community. By using this technique in the pipeline execution, I represent words in numerical values and later rank them in order of importance. This approach serves as a baseline for further improvements. More detail about this algorithm can be found here. Did we achieve any success? One run of the multi-pipeline in our solution results in dashboards such as this one: As an end-user of these dashboards I can immediately conclude that the main source of questions are around GitLab CI, pipelines […]

Start-ups and small or medium-sized businesses (SMBs) face plenty of challenges, but several of those hurdles can be eased by adopting a DevOps platform. A DevOps platform can help not only address the issue at hand but the benefits can spread across the company, helping it grow in a competitive and unpredictable market. The United States alone is home to 32.5 million small businesses, making up 99.9 percent of all companies in the country, according to a 2021 report from the Small Business Administration’s Office of Advocacy. And all of these companies have a tough road to travel – so tough that 20 percent of U.S. small businesses fail within the first year, according to the U.S. Bureau of Labor Statistics. By the end of the fifth year, about 50 percent are shuttered. Stressed with common problems like worker overload, finding time for collaboration, and meeting customer and market needs, smaller businesses are under a lot of pressure. With SMBs and small or medium-sized enterprises (SMEs) facing such significant challenges, it only makes sense to streamline software development, speed up deployments, automate repetitive tasks and foster collaboration. Taking all those steps can greatly improve an SMB’s odds of success. Here’s how a DevOps platform can help take on some major SMB frustrations: Ease worker fatigue and improve work/life balance SMBs, by definition, have fewer employees than their larger, more-established competitors. That means there are fewer people to take on all the tasks that need to be done. And that’s no different for the software development team, which could very well be a team of one. With everyone in an SMB having to wear so many hats and take on so many different jobs, it can be exhausting. That’s not only hard on productivity, it’s hard on employees’ work/life balance, and therefore not good for the business or the workforce. A DevOps platform offers an environment that fosters communication, collaboration and automation, which help ease the burdens on the IT staff. This will help get work done more efficiently and faster, leaving employees with more time for other projects. Satisfy customers How can you find new customers when you’re not a household name? You do it by keeping the buyers you have and pulling in more by satisfying, and even delighting, your customer base. Satisfied consumers stick around, buy more, and give free word-of-mouth marketing. A DevOps platform helps SMBs create customer satisfaction by automating the customer feedback process and accelerating software development and deployment. Increase communication and collaboration Workers in start-ups and small businesses often take on a multitude of projects, and try to chip away at their burgeoning workflows. Meetings – within a department or cross-functional – may be either low priority or tough to arrange. A “heads’ down” attitude is understandable, but means different demographics and perspectives often won’t come together to better innovate and create more well-rounded products for a wider range of consumers. A DevOps platform promotes collaboration by eliminating barriers not just between IT workers but within an entire company. And that leads to more innovative features and products, improves productivity, and keeps employees happier and more engaged. Collaborative workers also are continuously learning from each other. Adapt to the market with speed and agility Every market can be unpredictable. New competitors appear. Customer expectations […]

Even if you’re totally happy in your current position, it pays to keep an eye on your DevOps career path and learn about emerging roles, especially given the way the DevOps space evolves so rapidly. For example, you might be wondering about the role of site reliability engineer (SRE) as opposed to DevOps engineer (and the totally new position called DevOps platform engineer, more on that later). These are all engineering positions requiring tech expertise and coding chops, but they play distinct roles on the DevOps team. Here’s what you need to know: SRE: A seasoned role As the title suggests, at a high level, SREs focus primarily on reliability, solving operational, scale, and uptime problems. In 2003, Google originated the SRE role to safeguard the uptime of its site, but it has evolved considerably since the advent of cloud native applications and platforms. Today, SREs concentrate on minimizing the frequency and impact of failures that can impact the overall reliability of a cloud application. According to Glassdoor, SREs typically require a Bachelor’s or graduate engineering or computer science degree. Salaries range widely, according to Glassdoor, hitting about $120,000 after 2 to 4 years of experience but can reach up to $300,000 and higher at the senior level. At least one blogger feels the SRE title carries more prestige and earning potential than DevOps engineers. Typical SRE responsibilities include everything from designing, developing, installing, and maintaining software solutions to working with engineering teams to refine deployment and release processes. Collaboration and communication are important job skills for the SRE role, as they need to work closely with multiple roles across the organization. At the time of this blog’s publication, there were 4,000 SRE jobs on Glassdoor. Indeed had more than 5,000 SRE postings and ZipRecruiter showed nearly 12,000 posts for remote SRE jobs. Python, Go, and Java were the most sought-after SRE skills listed on Indeed. According to Indeed, SREs transition to “DevOps engineer” at a high rate. DevOps engineers bridge the gap DevOps engineers, on the other hand, concentrate on removing obstacles to production and automation and making development and IT work well together. Like SREs, DevOps engineers need to be good at working and communicating with others, eliminating barriers to increase speed and quality of code delivery. With typically less need to be on call, the DevOps engineer may have a more favorable work-life balance than an SRE, who can have around-the-clock call. DevOps engineer work responsibilities include such things as analysis of technology utilized within the company and then developing steps and processes to improve and expand upon them. Project management is another key function, establishing milestones for departmental contributions and establishing processes to facilitate collaboration. The educational requirements for the two roles are comparable, with a Bachelor’s degree in computer science or engineering or higher as the usual price of admission. According to Glassdoor, the salary range for DevOps engineers is slightly lower than that of SREs, from a low of about $63,000 up to a high of $234,000 for someone with 2 to 4 years of experience. DevOps engineer positions are easier to find than SREs. Glassdoor has more than 6,000 DevOps engineer job posts. Indeed has more than 17,000. And ZipRecruiter has more than 81,000 remote DevOps engineer listings. New to the game Cloud […]

Accelerating DevOps adoption is core to achieving our mission of allowing everyone to contribute. DevOps enables contribution and collaboration between disparate and previously siloed teams. In fact, DevOps is so central to GitLab that we have incorporated the DevOps infinity loop into our logo. I’m excited to share our new logo and look with you. Building the One DevOps Platform DevOps has come a long way since GitLab was incorporated in 2014. And DevOps strategies are continuing to evolve. For some companies, each team selects their own DevOps tools, which causes problems when teams try to collaborate. For other companies, they select a set of preferred tools. But then they still require a lot of custom work to integrate DevOps point solutions together into a “Do It Yourself DevOps” solution. The more point solutions that are digitally duct taped together, the harder it is to integrate and maintain them all. And that’s why I’m proud that GitLab allows companies to do away with the many point solutions that have been digitally duct taped together and instead bring all DevOps functionalities together in ONE place. As someone who is passionate about single sources of truth for information, the concept of One resonates with me. There are many ways in which GitLab as The One DevOps Platform helps customers evolve their DevOps landscape and deliver better results for their organizations. One interface One data model One permissions model One value stream One set of reports One spot to secure your code One location to deploy to any cloud One place for everyone to contribute One. Platform. Today, all companies live and die on their ability to create and deliver software. This is true for every type of organization, from the largest global commercial enterprises to the emerging hypergrowth startups. That is why companies such as Siemens, T-Mobile, and UBS, have selected GitLab as their DevOps platform. “Having the ability to fully develop software in the cloud through GitLab is a game changer, allowing us to accelerate our tech strategy and offer a best-in-class engineering experience. It also means we’re able to constantly develop, test and deploy technical solutions while they are running, improving time-to-market for our clients while decreasing costs.” – Mike Dargan, Chief Digital and Information Officer at UBS. Evolving the GitLab brand, iterating our logo and look Iteration is deeply ingrained in our values. We strive to do the smallest thing possible to get to the best result as quickly as possible. This value leads to quicker learning and tighter feedback loops. I see this moment both as a symbol of GitLab’s growth and of the evolution of DevOps itself. To reinforce this moment, we are also evolving our logo. The new logo places GitLab at the center of the DevOps infinity loop. I am pleased that we chose to iterate instead of a step change – staying true to our values. And we’re just getting started I aspire for GitLab to represent a place where we elevate others through knowledge access, job access, and The One DevOps platform. More to come later this year as we work to help individuals elevate their careers by learning core DevOps principles and how to use GitLab. Thank you to our amazing customers for choosing GitLab as your One DevOps Platform. Most importantly, […]

Even if you’re totally happy in your current position, it pays to keep an eye on your DevOps career path and learn about emerging roles, especially given the way the DevOps space evolves so rapidly. For example, you might be wondering about the role of site reliability engineer (SRE) as opposed to DevOps engineer (and the totally new position called DevOps platform engineer, more on that later). These are all engineering positions requiring tech expertise and coding chops, but they play distinct roles on the DevOps team. Here’s what you need to know: SRE: a seasoned role As the title suggests, at a high level, SREs focus primarily on reliability, solving operational, scale, and uptime problems. In 2003, Google originated the SRE role to safeguard the uptime of its site, but it has evolved considerably since the advent of cloud-native applications and platforms. Today, SREs concentrate on minimizing the frequency and impact of failures that can impact the overall reliability of a cloud application. According to Glassdoor, SREs typically require a Bachelor’s or graduate engineering or computer science degree. Salaries range widely, according to Glassdoor, hitting about $120,000 after 2 to 4 years of experience but can reach up to $300,000 and higher at the senior level. At least 1 blogger feels the SRE title carries more prestige and earning potential than DevOps engineers. Typical SRE responsibilities include everything from designing, developing, installing, and maintaining software solutions to working with engineering teams to refine deployment and release processes. Collaboration and communication are important job skills for the SRE role, as they need to work closely with multiple roles across the organization. At this writing, there were 4,000 SRE jobs on Glassdoor. Indeed had more than 5,000 SRE postings and ZipRecruiter showed nearly 12,000 posts for remote SRE jobs. Python, Go and Java were the most sought-after SRE skills listed on Indeed. According to Indeed, SREs transition to “DevOps engineer” at a high rate. DevOps engineers bridge the gap DevOps engineers, on the other hand, concentrate on removing obstacles to production and automation and making development and IT work well together. Like SREs, DevOps engineers need to be good at working and communicating with others, eliminating barriers to increase speed and quality of code delivery. With typically less need to be on call, the DevOps engineer may have a more favorable work-life balance than an SRE, who can have around-the-clock call. DevOps engineer work responsibilities include such things as analysis of technology utilized within the company and then developing steps and processes to improve and expand upon them. Project management is another key function, establishing milestones for departmental contributions and establishing processes to facilitate collaboration. The educational requirements for the two roles are comparable, with a Bachelor’s degree in computer science or engineering or higher the usual price of admission. According to Glassdoor, the salary range for DevOps engineers is slightly lower than that of SREs, from a low of about $63,000 up to a high of $234,000 for someone with 2 to 4 years of experience. DevOps engineer positions are easier to find than SREss. Glassdoor has more than 6,000 DevOps engineer job posts. Indeed has more than 17,000. And ZipRecruiter has more than 81,000 remote DevOps engineer listings. New to the game Cloud native development and the desire to […]

GitLab is now an approved vendor under the Software Licensing Program (SLP) with the state of California. This contract allows state and local agencies, including educational institutions in California, to purchase GitLab software licenses at an agreed-upon discount, reducing costs and streamlining the procurement process. Under the contract, agencies will have greater access to GitLab’s complete DevOps solution, which empowers organizations to deliver software faster and more efficiently. Established in 1994, California’s SLP is managed by the Procurement Division of the Department of General Services. The program provides government agencies and institutions with discounted rates for software licenses and upgrades, reducing the need for individual departments to conduct repetitive acquisitions. “There’s an exciting opportunity for public sector agencies to benefit from automated DevOps practices,” says Bob Stevens, GitLab’s area vice president for Public Sector Federal. “This contract makes it simpler and more cost-effective for agencies to adopt The DevOps Platform, and deliver more resilient and efficient applications while keeping security at the forefront.” GitLab believes that this contract, which makes The DevOps Platform more accessible and cost-effective, will expedite the broader adoption of DevOps in the public sector. GitLab’s single application will enable greater collaboration within public sector agencies, allowing teams to partner on planning, building, securing, and deploying software. To streamline the process, GitLab will work with channel partners including Acuity Technical Solutions, Launch Consulting and Veteran Enhanced Technology Solutions. “Public sector agencies are under tremendous pressure to transform and streamline their software development processes,” said Michelle Hodges, GitLab’s vice president of global channels. “We’re proud to extend the power of our platform to a new network of customers via trusted channel partners and to help evolve the ways in which they collaborate on and deliver software.” “Find out how state and local agencies in California can purchase @gitlab licenses at a discount.” – Click to tweet

Accelerated adoption of the cloud requires tools that aid in faster software delivery and performance measurements. Delivering visibility across the value chain, the DORA metrics streamline alignment with business objectives, drive software velocity, and promote a collaborative culture. Software delivery, operational efficiency, quality – there is no shortage of challenges around digital transformation for business leaders. Customer satisfaction, a prominent business KPI, has paved the way for experimentation and faster analysis resulting in an increased volume of change in the software development lifecycle (SDLC). Leaders worldwide are helping drive this culture of innovation aligned with organization goals and objectives. However, it is not always about driving the culture alone; it is also about collaboration, visibility, velocity, and quality. Cloud computing and microservices are driving the cloud-first approach for software delivery, helping to scale them independently, and allowing teams to move faster. But, without DevOps, the team doesn’t have the underlying core to move fast efficiently. DevOps has the power to enable the smallest changes that can have great effects. This brings us to the question – how do you measure velocity and impact? Or how do you assess quality, and ensure that it is not hampered by velocity? The latter would be what is commonly referred to as technical debt. A continuous journey needs continuous improvement Any improvement starts with measurement. Measuring and optimizing DevOps practices improves developer efficiency, overall team performance, and business outcomes. DevOps metrics demonstrate effectiveness, shaping a culture of innovation and ultimately overall digital transformation. In the Accelerate State of DevOps 2021 report by the DevOps Research and Assessment (DORA) team at Google Cloud, which draws insights from 7 years of data collection and research, four metrics are the key to measure software delivery performance. What are these metrics? Deployment Frequency Lead time for changes Time to restore service Change failure rate Deployment Frequency Let’s start with the velocity of development. Deployment frequency measures how often the organization deploys code to production or releases it to end users. This metric borrows from lean manufacturing concepts, wherein small multiple batch sizes are the preferred approach for higher efficiency and more rapid adjustments. Lead time for changes Now comes the extent of automation in your processes. Lead time for changes measures the time needed to take a committed code to successfully run in production. This is one of the two metrics with significant variance in the data. Time to restore service This represents a business’ capacity. Time to restore service measures the time needed to restore services to the level they were previously, in case of an incident. Here too we see significant variance in the data. Change failure rate And finally, we take a look at quality. Changes which cause a failure in the system – a deployment failure, an incident, a rollback or a remedy – all contribute to measuring the change failure rate. Driving visibility into the DevOps lifecycle Recently, Zoopla used DORA metrics to boost deployments and increase automation. Understanding the root cause of their problems helped them make informed adjustments in their process workflows, automation, tools, and more. They recognized the value of using a single platform to overcome roadblocks in velocity and innovation. This brought added visibility into their system which helped improve measurement and analytics. Our 2021 Global DevSecOps Survey shows […]

A successful DevOps practice relies heavily on metrics. Here at GitLab, we use seven key DevOps metrics to measure engineering efficiency and productivity. Like many teams, we use industry standard metrics, but in some cases, we approach this data with a unique GitLab point of view. Here’s the first in a multipart look at the DevOps metrics we at GitLab think are most critical for success. Compare your metrics and results with ours, and let’s get a conversation started. Master pipeline stability It’s important to be able to measure the stability of the GitLab project’s master branch pipeline. This metric tells us how stable the main branch is, and ensures engineers are checking out code that’s in good shape. Merge trains are key to this effort. Our target percentage for master pipeline stability is above 95%. Review app deployment success rate At GitLab we take review apps seriously. We measure their success rate so we can understand the stability of our first deployed environment after code change. Review apps are spun up at MR submission. It’s important to monitor our review app successful deployments because it’s the first place where code is integrated and deployed as one unit. This metric ensures the codebase can be installed, tested, and made available for the team to preview their changes before merging into the main master branch. Our target for review application deployment success is above 99%. Time to First Failure Time to First Failure (TtFF, pronounced as “teuf”) measures how fast we are providing feedback to engineers. This metric examines how long it takes from pipeline creation to the first actionable failed build. The idea is that if the commit is going to fail, it should fail fast and the fail signal should get to the engineers as quickly as possible. The shorter the time to first failure, the faster the feedback loop, and faster time to action to address those failures. Our TtFF target is less than 15 minutes. Open S1 bug age This metric focuses on the age of open S1 bugs. Many organizations measure time to close bugs. At Gitlab we focus on the age of bugs remaining. We structure the metric to focus on work that is remaining and can be actioned on. If we only measure time to close of fixed defects, we may miss addressing older defects and unintentionally incentivize closing of only newer defects. We like to look forward by asking ourselves “What’s left?” and “What can be done now?” rather than only looking backward at what’s already been done. Our target for S1 open bug age is under 100 days. Open S2 bug age This metric is similar to the open S1 bug age, but is focused on S2 bugs. Again, we measure the age of remaining open bugs rather than focusing on bugs that have been closed. Our target for the open S2 bug age metric is below 300 days. Merge request pipeline duration When a pipeline is started for a merge request, how long does it take to run? This metric focuses on the duration of merge request pipelines and its time efficiency. Within the total duration we break the data down into multiple stages The team then iterates and improves time efficiencies of each stage of the pipeline. This is a […]

If you work in an IT team of five people – or maybe you’re even a team of one – it’s easy to think your business is simply too small to use DevOps. But that’s not the case. A start-up or small and medium-sized business (SMB) is never too small to take advantage of a DevOps platform. In fact, DevOps is a great fit for a lot of SMBs, or small and medium-sized enterprises (SMEs). Here’s how to understand if it will work for your team or organization and how it could help grow your business in a competitive environment. The size of the business isn’t the issue Let’s be clear. If you are developing software, you need a DevOps platform. Size isn’t really the issue. No matter how small your business and your tech team, if you are iterating on software features, building applications, or automating parts of your product-related systems, then you do need DevOps. DevOps will even work for a team of one. Here’s how a DevOps platform can help an SMB: Start small to foster innovation One of the key aspects of DevOps is that it creates a collaborative atmosphere, even beyond the software and IT teams. Adopting a single, end-to-end DevOps platform when your company is small or your start-up is just getting off the ground will enable and encourage everyone – whether they’re in a technical role or work in accounting, sales or as a business manager – to all work together. And that will foster innovation by bringing in ideas from people in a range of demographics and business interests. And innovative ideas will help new businesses get a foot in the door and help all SMBs grow into more successful and bigger companies. Optimize your SMB for speed To get established in the market, start-ups and small businesses need to deliver compelling products quickly, and be able to efficiently support them. DevOps will enable your team to move from planning to production faster and with greater ease. A DevOps platform extends through the entire software development lifecycle, from planning all the way through to launching new features, conducting analysis, and gathering feedback. Simply put, DevOps will optimize your organization for speed, which is just what SMBs and SMEs need. Use DevOps to take on the “deep pockets” As an SMB, you likely don’t have the deep pockets and market penetration of your more-established competitors. How do you boost your odds when taking them on? One way to increase your competitiveness is to use DevOps to boost speed and efficiency as you create new products, new services, and new ways to communicate with your customers. When you can deploy innovative ideas faster than your competitors, you’ll have a definite advantage. Decrease your workload with automation When you have fewer hands to take on a huge workload, you need a way to not only speed production but to ease the number of tasks you’re facing – and all the headaches that come along with them. The automation that is part of a DevOps platform will mean less manual work when it comes to processes like design, testing, development, deployment, and monitoring. Automation helps small teams free up time to handle all the other projects on their to-do lists. Build security into software from the […]