Auto Deploy to EC2
Auto Deploy to EC2
Auto DevOps has been expanded to support deployments to Amazon Web Services. You can now deploy to AWS Cloud Compute (EC2) and take advantage of Auto DevOps, even without Kubernetes. To enable this workflow, you must enable Auto DevOps and define the AWS-typed environment variables AWS_ACCESS_KEY_ID
, AWS_SECRET_ACCESS_KEY
, and AWS_DEFAULT_REGION
. This allows you to provision your own infrastructure by leveraging the AWS CloudFormation API. Then, you can push your previously built artifact to an AWS S3 bucket, and deploy the content to an AWS EC2 instance. Your EC2 deployment then automatically builds you a complete, automatic delivery pipeline without extra manual steps.
Postman collection support for API fuzz testing
Postman collection support for API fuzz testing
You can now use a Postman collection to do API fuzz testing! Postman collections are pre-defined descriptions of your APIs that you may have already created as part of your testing efforts. It’s straightforward to create them if you haven’t already done so.
This is a great way to use fuzz testing with the resources that you
already have. To use a Postman collection with fuzz testing, add the
Postman collection to your repo and indicate its location in the
.gitlab-ci.yml
file. The fuzz engine then references it to do fuzz
testing.
API fuzz testing with a Postman collection runs all the same checks as fuzz testing with an OpenAPI specification or an HAR recording. We have an example project you can look at to quickly get started!
Display Code Quality severity ratings
Display Code Quality severity ratings
The Code Quality feature in GitLab is great at showing what quality violations exist in a project or are changing in the Merge Request. However, understanding which of those violations is the most important is not clear in the GitLab interface today.
With the Full Code Quality Report and Merge Request Widget, now you can see the severity rating. This makes it easy for you to understand which code quality violations are most important to resolve before merging and reduces the technical debt in your project.
Display code coverage data for selected projects
Display code coverage data for selected projects
In 13.4, we released the first iteration of Code Coverage data for Groups that enables you to compare the coverage of multiple projects and download the data in a single file from a single screen. However, to analyze the data, you had to open the file to check it manually, and probably imported it into a spreadsheet for further analysis. In GitLab 13.6, you can now select specific projects in a group to see their latest coverage values directly in GitLab itself without needing to download a file or waste development time accessing code coverage data. We welcome feedback on the functionality and possible iterations for this feature in our feedback issue.
Define test cases in GitLab
Define test cases in GitLab
The first step towards project-level quality management is here! This initial release allows users to define and view test cases from within GitLab.
Keeping all of your quality management tools in a single DevOps system is essential to ensuring a single source of truth and a single place for all participants to collaborate and understand context. Being able to define test cases from within GitLab is the first step in this vision. We intend to build upon this foundation with the creation of Test Sessions, an overall quality management dashboard, and the ability to view test histories across multiple deployment targets, such as staging and production.
Group-level management of project integrations
Group-level management of project integrations
In GitLab 13.3, we added the ability to enable an integration across an entire instance. With GitLab 13.6, that feature is being expanded to allow integrations to be managed at the group level as well!
Group owners can now add an integration to a group, and that integration will be inherited by all projects under that group. This has the potential for saving massive amounts of time, as many organizations have specific integrations that they want rolled out to every project they create.
A great example of this is using our Jira integration. If you’re using Jira, it’s almost always across the whole company. Some of these companies have thousands of projects and therefore had to configure each and every one of those integrations individually.
With group-level management of project integrations, you can add the integration at each parent group, reducing the amount of configuration required by orders of magnitude!
Read more in our announcement on the GitLab blog.
Milestone Burnup Charts and historically accurate reporting
Milestone Burnup Charts and historically accurate reporting
A milestone or iteration burndown chart helps track completion progress of total scope, but it doesn’t provide insight into how the scope changed during the course of the timebox. Neither has it previously retained historical accuracy regarding how much of the initial committed scope of the milestone or iteration was actually completed.
To solve these problems and help teams have better insights into scope creep, milestones and iterations now show a burnup chart that tracks the daily total count and weight of issues added to and completed within a given timebox.
We also refactored burndown charts to use immutable resource state events that ensure that milestone and iteration charts remain historically accurate[1] even after you’ve moved issues to another timebox.
[1] Only applies to milestones and iterations created in GitLab 13.6 or later. Milestones created prior to 13.6 will still have access to legacy burndown charts.
Change Canary weights through the API
Change Canary weights through the API
Adding support for canary-weight ingress annotation is a first iteration towards implementing a load balancer in GitLab. The goal is to provide you with an easy way to configure NGINX annotations so you can customize their behavior. Simply put, this gives you additional flexibility when configuring advanced deployments. Previously, changing canary weights was only supported in the .gitlab-ci.yml
file. You now have more control over your advanced rollouts, as well as the ability to introduce trigger-based rollouts.
Fire Webhook on Feature Flag change
Fire Webhook on Feature Flag change
As a developer, you can use GitLab’s webhook features for various events, such as MR events, pipeline events, job events, and deployment events. In this release, you can now use webhook events when a feature flag is toggled either on or off. This addition streamlines the process to update your CI/CD pipelines, receive Slack notifications for events, and more. A huge thanks to Sashi for a great community contribution!
Sort releases by name in UI
Sort releases by name in UI
A Release Page can be both confusing and difficult to navigate if you have hundreds of release tags with release notes. With the implementation of a new sorting component, gone are the days when you needed to manually sift through your releases each time you deploy. You can now quickly sort releases by date and name to find relevant information more efficiently.
We want to hear from you
Enjoyed reading this blog post or have questions or feedback? Share your thoughts by creating a new topic in the GitLab community forum.
Share your feedback