News Releases Hello everyone, RubyMine 2022.1 is now available! Below is a brief overview of the most notable features. For a detailed description of this update, please visit our What’s New page. Support for new language features RubyMine 2022.1 includes support for most of the new Ruby and RBS features introduced in Ruby 3.1, such as bounded generics, RBS collection, anonymous block argument forwarding, generic type aliases, and more. UX improvements The user experience has been refined with a redesigned New Project dialog, support for new Rails 7 generate options, and improvements for notifications, search, and the debugger UI, as well as performance and accessibility enhancements. New inspections and quick-fixes This version adds new inspections and quick-fixes for projects that use RBS type signatures. For example, RubyMine now checks the usage of type variables in RBS, and it reports inferred types in Ruby code that don’t match the expected types from RBS. Check out the What’s new page to learn about new features for the code editor, tests, Docker support, VCS integration, and more. DOWNLOAD RUBYMINE 2022.1 Happy developing!The RubyMine team
Features Releases This release has been focused on improving Scala 3 support. There are also several new features to help with day-to-day Scala programming. Let’s take a closer look: 1. Scala 3 support improvements2. New Scala project wizard3. Alias exports4. Unused declaration inspection5. Scala debugger upgrades Scala 3 support improvements This release includes many Scala 3 support improvements: It is now possible to autocomplete extension methods (to see methods from other objects, press Ctrl+Alt+Space twice). The editor offers to import extension methods and given instances automatically. New inspections for the infix modifier and @targetName annotation can help you maintain a consistent code style. We’ve significantly improved the performance of the .tasty reader, so indexing Scala 3 libraries is now up to twice as fast. New Scala project wizard Configuring a new Scala project just got easier! With the updated New Project wizard, you can select a JDK, desired build system, and Scala version for your project in a single step: Alias exports Most things in Scala are aliases, including String, Seq, List, Set, and Map. This affects syntax highlighting, GoTo, Quick Documentation, Quick Definition, Find Usages, Optimize Imports, and other IDE features, because they act on aliases rather than actual definitions. To improve the user experience, the editor now treats aliases in the standard library as transparent exports, so, for example, List implies scala.collection.immutable.List rather than scala.List: Unused declaration inspection Previously, the detection of unused declarations was limited to private bindings. Now the Unused declaration inspection supports public bindings introduced by classes, methods, variables, parameters, and so on: Currently, this functionality has to be enabled in the inspection settings (Settings | Editor | Inspections | Scala | General | Unused declaration), but we will enable the feature by default in the bug-fix release. Scala debugger upgrades In this release, we’ve made an effort to revamp and streamline the Scala debugger. We’ve upgraded the handling of objects, primary constructor parameters, value classes, Arrays, lazy vals, and collections, in addition to improving expression evaluation: As always, your feedback is very welcome. Please report any issues you find to YouTrack. If you have any questions, feel free to ask us on Discord. Happy developing! The IntelliJ Scala plugin team
News We have all of the March news for you in our latest monthly C++ Annotated digest. Read the monthly digest on our blog and subscribe to C++ Annotated emails by filling out this form. Language news C++ Committee news February’s virtual plenary was the official feature freeze date for C++. Since then, it has become noticeably quieter around the C++ Standards Committee. During the last couple of months, the Library Evolution Study Group has been working on various fixes to existing language features that have been improved for C++23, such as ranges and formatting. They’ve also been polishing the API of new features already accepted for C++23, in particular mdspan, which is now looking really good. The Language Evolution Study Group is similarly focused on various smaller bug fixes for language features. We now also definitely know that we will not be getting executors or networking in C++23, two of the four items that were originally prioritized for C++23 according to the “overall plan for C++23” proposal. The three language features mentioned in that plan (reflection, pattern matching and contracts) are also nowhere near ready yet. As a result, the largest core language feature that is actually going to land in C++23 is deducing this. C++23 was never going to be as large a release as C++20 was, but it also seems that the pandemic and the need to move all standardization work from in-person to online meetings significantly hampered progress. During the last couple of months, I (Timur) was mostly active in the Core study group that finalizes the wording for language features, where my paper on portable assumptions is now in the final stages of wording review. I am firmly expecting that it will be voted into C++23 at the next plenary session. I also participated in the Contracts study group (SG21), which is currently rather stuck on the question of whether or not the expressions inside a contract annotation should be allowed to have side effects, and what exactly would happen if they did. Various opinions exist, and it will take more work before we reach a consensus and can formulate a specification, but hopefully this will happen in time for C++26. The current state of this work is now being tracked in the newly established Contracts Working Paper. Expect the standard committee work to remain relatively quiet for the next few months. We are now finalizing all outstanding fixes for the July 2022 online plenary session. This is where we will finalize the C++23 wording for the committee draft, which then goes out for review by the individual national bodies. Learning SFINAE, overload resolution, and a surprising error A new blog post at C++ stories highlights an interesting aspect of SFINAE. The sample used in the article performs the basic operation of printing a tuple via the stream output operator. The custom operator throws a surprising compiler error when printing of the ‘n’ symbol is called. And even more surprisingly, the code doesn’t work for std::tuple_size_v but works when using std::tuple_size::value inside the implementation. The author digs deeper into the reasons why std::tuple_size_v doesn’t work for TupleT=char. An interesting discovery here is that the immediate context matters. While the compiler recognizes immediately whether std::tuple_size::value is valid or not, in the case of std::tuple_size_v it has […]
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 […]
We want to share the actions we’ve taken in response to the critical Spring remote code execution vulnerabilities (CVE-2022-22965 and CVE-2022-22963). Upon becoming aware of the vulnerabilities, we immediately mobilized our Security and Engineering teams to determine usage of this software component and its potential impact within our product, across our company, and within our third-party software landscapes. At this time, no malicious activity, exploitation, or indicators of compromise have been identified on GitLab.com. Further, our product packaged Java components for both GitLab.com and self-managed instances do not use vulnerable Spring components, and thus are not vulnerable. Our teams are continuing to investigate and monitor this issue to help protect our products and customers. We will update this blog post and notify users via a GitLab security alert with any future, related updates. More information “Actions @Gitlab has taken to investigate the Spring remote code execution vulnerabilities CVE-2022-22965 and CVE-2022-22963.” – GitLab Click to tweet
It is possible to use GitLab as a best-in-class GitOps tool, and this blog post series is going to show you how. GitOps is an operational framework that takes DevOps best practices used for application development such as version control, collaboration, compliance, and CI/CD tooling, and applies them to infrastructure automation. This series of easy-to-follow tutorials will focus on different user problems, including provisioning, managing a base infrastructure, and deploying various third-party or custom applications on top of them, that can be solved by pairing GitOps with GitLab. Here are 8 tutorials on how to do GitOps with GitLab: 1. Here’s how to do GitOps with GitLab This tutorial sets the stage for what you will learn throughout the series, including the tech concepts you’ll need to know. 2. Infrastructure provisioning with GitLab and Terraform This tutorial walks you through setting up the underlying infrastructure using GitLab and Terraform. 3. Connect with a Kubernetes cluster This tutorial demonstrates how to connect a Kubernetes cluster with GitLab for pull- and push-based deployments and easy security integrations. 4. How to tackle secrets management This tutorial builds on the previous tutorial to show you how to use a Kubernetes cluster connection to manage secrets within a cluster. 5. The CI/CD tunnel This tutorial introduces you to CI/CD tunnels and shows step-by-step how to access a Kubernetes cluster using GitLab CI/CD. 6. Connecting GitLab with a Kubernetes cluster – Auto DevOps This tutorial looks at how you can use Auto DevOps with all its bells and whistles to easily manage deployments. 7. Connecting GitLab with a Kubernetes cluster for GitOps-style application delivery This tutorial shows you how to connect an application project to a manifest project for controlled, GitOps-style deployments. 8. Turn a GitLab agent for Kubernetes installation to manage itself This tutorial is the culmination of the previous tutorials and will teach you how to turn a GitLab agent for Kubernetes installation to manage itself. Read more about GitOps: “Want to learn how to pair GitOps with GitLab? Our eight-part in-depth tutorial series will take you step by step.” – Viktor Nagy Click to tweet
Seventeen years ago, the Linux community embraced Git as its universal open source version control solution. Created by Linus Torvalds, Git replaced BitKeeper, a proprietary but free-of-charge option that worked, to a point, until it didn’t (and ultimately started costing a fee). In the years since, there’s been little to no agreement on what the term “Git” actually means but there’s no disputing its rockstar status in the DevOps world. Tens of millions developers rely on Git’s fast and seamless branching capabilities every single day. In fact, 85% of DevOps professionals who took our 2021 Global DevSecOps Survey said they use Git for source control. So, to honor this anniversary, we share our favorite Git tips and tricks and look back at the origins of its name, its 15th anniversary celebration, and even a declaration from one of our own who was certain Git would never be in his toolkit. No, really. The origin of the name Git There’s not much quirky or charming about the world of DevOps, but the theories around the origin of the name Git may be an exception. Torvalds claimed to have named Linux after himself, and he said Git (British slang for “jerk”) was no different. “I’m an egotistical b*stard, and I name all my projects after myself,” he said at the time. The source code’s README takes the story in a different direction: Git is easy to pronounce, not used by UNIX, and could sound like “get.” It could be British shade-throwing, or it could stand for “global information tracker” (the choice of those happily working with a functioning tool). And for those frustrated with Git, there’s also “goddamn idiotic truckload of sh*t.” Tips and tricks for better Git Is it possible to improve on a tool that so many use every single day? Actually, it is, starting with 15 ways to get a better Git workflow. Learn how to: autocomplete commands use Git blame more efficiently reset files understand the plugins Also, Git can help keep merge requests tidy and humming along. For an exhaustive look at how GitLab uses Git internally, including .gitconfig on steroids, the lowdown on aliases, and command line tips, we’ve gathered a life-changing list. Also, here’s our take on why (and how) to keep your Git history clean and how to do it using interactive rebase. Remembering the 15th anniversary celebrations Landmark anniversaries always make people reflect, and Git’s 15th in 2020 was no exception. Not only was there an actual party – Git Merge 2020, our staff developer evangelist Brendan O’Leary admitted the unthinkable: Back in the day, he was never ever going to use Git. Brendan, who obviously has learned his lesson, also teamed up with GitHub’s distinguished software engineer Jeff King to talk about Git’s impact on software development. Practical Git Although there’s a lot to learn about Git, Brendan and other developers consistently stress the simplicity is what sets it apart. So here are three of our most bookmarked pages of straightforward Git advice: 6 common Git mistakes and how to fix them Understand the new Git branch default name A guide to Git for beginners So make sure to raise a glass to 17 years of Git and its many benefits. “It’s the 17th anniversary of #Git today. Here are our favorite […]
A small or medium-sized business (SMB) or enterprise (SME) is likely working with a small staff but facing a big workload and even bigger expectations. Creating applications that will expand the customer base, keep up with a changing market, and take on competitors with deeper pockets can be daunting. It’s possible to ease those burdens by choosing a single, end-to-end DevOps platform. Productivity will skyrocket and so will opportunities to grow the company. Of course, DevOps offers significant technical benefits, like testing and building at scale with continuous integration and continuous delivery, a shorter lead time with automated deployment, and fewer production failures with earlier error detection. But a DevOps platform also offers myriad business benefits to help support and expand a start-up or SMB. Here are six more ways a DevOps platform can help an SMB: Improved customer satisfaction Using a DevOps platform means iteration can happen faster. And that’s critical for SMBs that need to be able to quickly make changes to meet customer needs. DevOps also provides a way to better monitor users’ feedback and makes it easier to respond with more speed and agility. And it reduces Change Failure Rates, increasing application reliability and stability. All of this means SMBs will be more able to give clients what they want and need, all while creating an engaging customer experience. Closer customer ties create trust and keep users loyal to products. Better security A DevOps platform embeds security to help seamlessly achieve a DevSecOps approach, a cornerstone of incorporating security scanning early in the software development lifecycle. By integrating testing and security reviews earlier in the process, and by using end-to-end automation, there are more opportunities to quickly and efficiently address any security issues. This reduces the time between designing new, higher-quality features and rolling them out into production. That’s the beauty of a platform approach to DevOps – security isn’t an afterthought. It’s part of the entire process. DevOps not only speeds production but creates more secure applications. And, simply put, more secure software makes for a more trusted product offering… and for happier, more satisfied customers. True collaboration and innovation Collaboration is one of the basic tenets of DevOps. By fostering communication and innovation, DevOps not only encourages developers and IT to work together, it also supports collaboration throughout the entire company. This is one area where SMBs have a huge advantage: With fewer employees, who also might be less set in their ways, collaboration and innovation are inherently more inclusive in a small business. An SMB or start-up is never too small for DevOps. By inviting discussion and assistance from all team members, DevOps creates a culture built around learning from and relying on others’ expertise; it also brings more ideas to the table. Happier employees and better retention The greatest resource a company has is its people. This is even more true for small companies where the pain of employee dissatisfaction and departure is felt even more acutely. Managers also don’t want projects waylaid because the people driving them are leaving. To stop that from happening, it’s critical the workplace keeps employees happy. Retaining a tech team isn’t just about perks, like in-office meditation pods, cereal stations, and foosball tables. Companies also need to give developers the processes and tools they need to […]
This blog post and linked pages contain information related to upcoming products, features, and functionality. It is important to note that the information presented is for informational purposes only. Please do not rely on this information for purchasing or planning purposes. As with all projects, the items mentioned in this blog post and linked pages are subject to change or delay. The development, release, and timing of any products, features, or functionality remain at the sole discretion of GitLab Inc. In the coming weeks, we will begin the second phase of the rollout of the new version of the Container Registry on GitLab.com. Prior to deploying this update, we wanted to clearly communicate the planned changes, what to expect, and why we are excited. If you have any questions or concerns, please don’t hesitate to comment in the epic. Context In Milestone 8.8, GitLab launched the MVC of the Container Registry. This feature integrated the Docker Distribution registry into GitLab so that any GitLab user could have a space to publish and share container images. But there was an inherent limitation with Docker Distribution, as all metadata associated with a given image/tag was stored in the object storage backend. This made using that metadata to build API features (like storage usage visibility, sorting, and filtering) unfeasible. The most recent Container Registry update added a new PostgreSQL backend, which is used to store the metadata. Additionally, this new version also includes an automatic online garbage collector to remove untagged images and recover storage space. In November 2021, we started phase 1 of the migration. This completed in January 2022 without any significant issues. Since then, every new image repository pushed to GitLab.com uses the new, metadata database-backed registry. Today, nearly 20% of Container Registry traffic is already routed to the new version. Now we are ready to begin Phase 2 of the migration. This will migrate image repositories created before January 22, 2022, to the new Container Registry. Once complete, we can unblock many of the features that you’ve been asking for. Why we are excited The plan We’re planning a phased migration, starting with GitLab.org repositories. After that, we’ll move on to the Free tier, then on to Premium and Ultimate. We’ll roll this out incrementally to maintain safety for customers and provide our team with an opportunity to identify and address any concerns. Timing Migration begins: April 18th, 2022 Migration ends: July 8th, 2022. Tentative dates by tier: GitLab internal projects: April 14 – April 18 Free: April 18 – May 18 Premium: May 18 to June 18 Ultimate: June 18 to July 8 For more information about the planned, percentage-based rollout, please refer to this epic. What to expect For each repository, the migration will only target tagged images. Untagged and unreferenced manifests, and the layers they reference, will be left behind and become inaccessible. Untagged images were never visible through the GitLab UI or API, but they were left behind in the backend after becoming dangling. Once migrated to the new registry, repositories will be subject to continuous online garbage collection, deleting any untagged and unreferenced manifests and layers that remain as such for longer than 24 hours. To ensure data consistency, the migration of each repository requires the enforcement of a small read-only period at the […]
Invormațiile pe cale Dvs le introduceți în prezentul formular nu se păstrează online, dar se vor transmite direct la destinație. Mai multe informații găsiți în Politica Noastră de Confidentialitate
We use cookies to ensure that we give you the best experience on our website. If you continue to use this site we will assume that you are happy with it.
