Source: GitLab Blog | Author: Tim Rizzi
GitLab 12.8 버전은 “one place!”를 축하하고 있습니다. GitLab이 전체 DevOps 라이프사이클을 위한 한 곳인 것처럼 당신의 로그, NuGet 패키지, 컴플라이언스 활동을 위한 한 곳에서 모아 보십시오.
Triage faster with the new Log Explorer
When triaging an incident or validating the status of your service you need to be able to explore Kubernetes Pod Logs from across your entire application. Previously, this was a painful process as you could only see limited logs, couldn’t go back in time, and didn’t have search. This was complex and time-consuming enough that it could make using Pod Logs impractical for meaningful analysis and instead limit it to simple troubleshooting use cases.
Now, a new Log Explorer lets you interact with all your logs aggregated into one place. Powerful features including filtering, time picker, and full-text search let you quickly get the information you need. This important milestone moves our Logging category from
viable! To get started, install the Elastic stack on your Kubernetes cluster with just one click using the GitLab Managed app, and your logs will be automatically collected and aggregated.
Efficiently store and share C# and .NET resources
Windows has a large, active, and growing development community. While GitLab has already had built-in package management for C/C++, Java, and Node.js, teams writing applications in C# and .NET still needed to use tools external to GitLab in order to store and manage their binaries. This meant they were missing out on the benefits of using a single application across their DevOps lifecycle.
Now, GitLab 12.8 gives teams writing code in C# and .NET a built-in NuGet repository so they have one place to manage and share project binaries both privately and publicly. Developers can now benefit from having their source code, CI/CD pipelines, and the resulting packages all in the same application so they can get work done faster with less effort.
Manage risk with the Compliance Dashboard
Merge requests (MRs) are an elegant and powerful change management tool for keeping a record of changes and approvals. Release teams use MRs to track deployments, and infrastructure teams use MRs to practice GitOps.
Additionally, tracking all MR activity can be critical for organizations that have specific company policies that govern their operations in order to adhere to compliance frameworks, such as SOC 2, ISO 27001, GDPR, SOX, HIPAA, or PCI-DSS, and have specific company policies that govern their operations.
Some examples of governing policies are:
- All MRs have a related issue with detailed information about the change(s)
- All MRs are reviewed and approved by someone who isn’t the author
- All MRs pass QA and security testing
- All MRs have a related issue with detailed information about the changes.
- All MRs are reviewed and approved by someone who isn’t the author.
- All MRs pass QA and security testing.
- Any exceptions to the requirements require separate approval.
Previously, GitLab users lacked the necessary tools to effectively manage their GitLab environment’s change management and compliance. Project-level activity was confined to each project, and there was no easy way to view this information in aggregate at the group level. This lack of control and insight created increased potential for risk, reducing users’ ability to manage compliance within GitLab.
We have a vision for adding robust compliance management to Gitlab. As a first step towards this vision, we’re starting with a Compliance Dashboard which provides a view of the most recent merge requests for each project in a Group. With the capabilities available today, you can manage auditing of your code changes for releases and GitOps from one place. Similarly, this makes it easier for compliance-focused organizations to quickly understand which projects might have greater risk and therefore warrant extra attention. Be on the lookout for more capabilities and improvements in our coming releases.