devopsy.kinsta.cloud

Tag: gitlab

How GitLab CI supported Ticketmaster’s ramp up to weekly mobile releases

It’s always been a goal for the Ticketmaster mobile team to get to weekly releases. In the first half of this year we were able to accomplish it, delivering new versions of both the Android and iOS app on a weekly basis since February. We’ve seen the positive impact on our fans, and it was even easier than we thought – making our entire application development process that much better.

But it didn’t start out this way…

A faster, more consistent release cycle leads to a better fan experience for users of the Ticketmaster Apps.

There comes a time in every engineer’s career when a part of your tech stack no longer passes the “smell test.” Usually, there is some sort of dramatic event where something that was generally accepted as “isn’t the best, but it works” changes to “this is now a problem.” For me and the Ticketmaster mobile team, this event happened with our Jenkins-based CI pipeline in February.

We were about to release the newest version of our Android app, but there was a mistake in the build. We had forgotten to increment the Android versionCode, meaning we would need to update and create a new binary file to upload to the store. It was the end of the day, a sunny afternoon quickly fading to darkness in Hollywood. By now it was 6pm PST, and everyone was eager to leave.

“No problem,” I thought. I can build the release locally in under three minutes, provide the file to the QA team, and we can all get on our way.

“Won’t help us,” responded my high-standard and exceptional QA team.

“All releases need to come from CI for consistency.” They were right. Local builds would not be safe for production. What if something about my machine’s configuration introduced an issue?

“Ok, so how long does it take for the release build to get created through our Jenkins CI pipeline?” I asked, figuring the time couldn’t be worse than 30 minutes.

“It takes two hours,” came the response. Sigh… Going to be a late night.

Our old CI pipeline

GitLab CI to save the day (in a day!)

Two… hours… For a minor change. Now I can’t lay all the blame on Jenkins. Some of this may have been our own fault, generating too many build flavors, forcing clean rebuilds in between steps and running extra tests for deprecated features. But, it was clear we needed to change and get better at CI. Jenkins was always a bit clunky for the last few years. Weighed down by plugins and years of legacy development, it was also difficult for us to update the Jenkins machines with new SDKs, and we had to rely on other teams to assist us. We clearly needed a fresh start.

We had been using GitLab at Ticketmaster for several years for code review and visually browsing our git history, so it made sense that trying to utilize GitLab’s new CI tools would be worth a shot. I started with a helpful Android blog post for setting up GitLab CI from Greyson Parrelli.

But I soon ran into a problem. At Ticketmaster we use Amazon ECR for our Docker container registry rather than GitLab repos, like in the tutorial. With the help of Kraig Amador, Tim Nichols, and others at Ticketmaster, I learned how to push my Docker container image to Amazon ECR and pull it down for each Android build in GitLab CI. The final results were a marked improvement:

Our GitLab CI build and test takes under 8 minutes to build, test, and publish artifacts.

Less than eight minutes total from commit to build, test and generate artifacts. We can use Gradle and the SonarQube plugin to help us calculate code quality with every commit to our codebase, giving us more valuable information in addition to passing failing tests to evaluate all of our merge requests. This gives our team numbers to measure and make goals against.

And we could see everything in one place, in GitLab. The iOS team had a more complicated pipeline, but they quickly followed with their own, running their tests on local runners. Since February we have had weekly releases of our mobile apps, and GitLab CI has been a huge part of our success over the past few releases.

From GitLab artifact to weekly releases

GitLab CI has helped us get to weekly releases with more consistent adoption of new releases.

With the benefit of faster cycle time, and faster releases, we have seen other benefits. Since each release has a smaller change set, our crash-free rates and store ratings have improved. We have less time waiting for build and spend more time improving the quality of our products. Our fans are getting features into their hands more quickly and benefit from a higher-quality and a consistently improving product. The CI analytics available on GitLab are an additional scoreboard for our team to optimize and improve into the future.

Now, whenever we integrate new SDKs into our mobile apps, we are helping other teams get their SDK’s set up in GitLab CI to push integrated builds to our suite of integration and functional tests as a part of our process. We are getting to innovation faster.

Things were looking pretty scrappy for our CI pipeline only a few months ago. Now it is a whole different ballgame. If your team is looking for a way to breathe fresh life into a legacy CI pipeline, I suggest taking a look at GitLab CI. It has been a real game changer for our mobile team at Ticketmaster.

About the Author

Jeff Kelsey is the Lead Engineer for Ticketmaster’s Android development team. Find him on twitter @jeffkelsey.

August 15, 2020
Increasing deployments to 10 times a day

BI WORLDWIDE (BIW) inspires people and delivers measurable business results. Inspired employees solve problems and create value. Inspired salespeople take risks and seize opportunity. And inspired channel partners and customers choose your brand every time. We work with great companies around the globe who know that extraordinary results can only be achieved when their business is energized by the people who make it happen.

the challenge

Updating legacy systems and moving to multi-tenant configuration

The BIW Corporate Product Development Team (CPD) was dealing with a large legacy codebase that was created years ago. They were looking to eliminate (or at least significantly reduce) manual testing and manual deployments to their on-premise infrastructure. They had maintenance backlogs, inefficiencies, and cross-organization visibility issues. The goal was to achieve operational efficiency by removing toolchain complexity.

The company was also trying to update the previous architecture of a single-tenant code-change-driven solution and upgrade to a multi-tenant configuration-driven solution. The legacy application installation pattern was to install from a fork that could (and would) be tweaked to a customer’s needs before deploying to the VMs. This pattern provided flexibility for customers but was inefficient and was time-consuming to maintain and upgrade.

“It was entirely time-consuming to apply all of those code changes,” said Adam Dehnel, product architect, BI WORLDWIDE. “As a result, we didn’t release as frequently because the application of a new release to those disparate installations was quite a process. That would cause us to try to get ‘all the features’ into each release which would then slow the process down more.”

the solution

Increasing development speed

The Corporate Product Development Team considered Git source code management while using CVS in 2014. At that time they achieved 9-month release cycles with another few months for the code to be distributed to the customer installations for the upgrade. This tempo impacted their pace of delivering to market and ability to respond to customer requests.

To help combat this pattern, the product architecture team was given the directive to rethink processes – essentially update and modernize everything. They had practices and tools in place at the time but were spending time on items that weren’t business differentiating features. They faced classic issues surrounding a lack of cross-team communication including inefficient mechanisms for intra-organization workflows and individualized toolsets.

One of the early moves to help solve these challenges was to migrate from CVS to Git for source control management. They experienced a self-described “painful transition to Git” because of the modernization efforts this move required. Once the initial move to GitHub was complete BIW began looking to automate the build, test and deployment process. As the first implementation of this, the team built a chain of tools with GitHub talking to Jenkins and then Checkmarx + WebInspect plus JIRA and Confluence for the setup to manage the full lifecycle microservices. While these tools were heading in the right direction, the organization was still facing challenges with toolchain complexity and experienced lost bug reports, constant context shifting and tool differences throughout the organization.

the results

Improving efficiency by moving to a single tool

The CPD team evaluated GitLab’s capabilities against their current toolset and against the competition and selected GitLab to help them achieve their next iteration. The group started looking at what tools they could remove to simplify their toolchain. The migration from their previous Git tools to GitLab was painless and they saw an immediate improvement of collaboration and release pace as a result of their move to GitLab.

The development, QA, UX and DevOps teams within CPD at BIW have been using GitLab since 2017. In June 2018, additional development groups started to move over to be able to easily track all features, stories, requirements and use cases in GitLab Issues. The next goal is to include ongoing bug tracking and expand GitLab to several new internal teams that will use it as a collaboration hub for future feature development requests and discussions.

“GitLab is currently running on a Rancher cluster and we’re using AWS Aurora Postgres + Elasticsearch to run it. And then we just recently migrated from a (different) Rancher cluster for our microservices to Amazon EKS and are also pushing our web applications to CloudFront,” Dehnel explains. “All of this deployment is running from GL pipelines. We are solidly in a good CI workflow with some applications in Continuous Delivery. Heading into 2020 we’re starting to push towards Continuous Deployment for all microservices and microexperiences. We hope to leverage some of the GitLab Kubernetes integrations and enhancements to make this transition less work and more consistent.”

The company recently started using GitLab Pipelines to scan (SAST + Dependency initially, but they plan on using DAST capabilities soon) and deploy legacy monolith installations for anyone that is running their install in AWS. Between this setup and the microservices running in GitLab pipelines the first four days of SAST/Dependency scanning the team performed over 300 scans. This scanning helped the team identify previously unidentified vulnerabilities and allowed them to rectify the situation going forward. GitLab’s pipelines allow everyone to use the same tooling for application scanning and deployment regardless of whether it is legacy or modernized.

While Dehnel admits that they are still using some classic methods, they now have teams that experience releases almost daily– down from the original pre-Git pace of a release every 9-12 months. BIW is using GitLab pipelines to deploy the legacy monolith to AWS. Within those pipelines, they are performing automated infrastructure provisioning, infrastructure as code, automated security tests, and application deployments.

The ultimate win for the company is that the corporate product development team is all working in the same place. The operations infrastructure team is now working from the same platform and using the same product for their software development lifecycle. The team is pushing all of their automation tools to the same place instead of working around a daisy chain of tools anymore.

“One tool for SCM+CI/CD was a big initial win. Now wrapping security scans into that tool as well has already increased our visibility into security vulnerabilities. The integrated Docker registry has also been very helpful for us. Issue/Product management features let everyone operate in the same space regardless of role.”

Adam Dehnel

product architect, BI WORLDWIDE

All information and persons involved in case study are accurate at the time of publication.

August 15, 2020
Axway realizes a 26x faster release cycle by switching from Subversion to GitLab

Inventors of the world’s first business rules engine, Règle du Jeu (RDJ), Axway has been helping businesses unlock the value of their data for nearly two decades. Their cloud-enabled data integration and engagement platform, Axway AMPLIFY, orchestrates cohesive customer experience networks, enabling organizations to generate the speed, power, and agility required to meet skyrocketing customer expectations.

As change agents for data integration, keeping pace and adapting quickly to today’s fast and fluid digital customer is mission critical for Axway’s research and development (R&D) engineering services teams.

the challenge

Legacy source code management and toolchain complexity limits worldwide collaboration

Serving over 11,000 companies spanning 100 countries, Axway’s R&D engineering services teams are spread across continents and time zones. With the teams working from nine different sites and using Subversion (SVN) on local servers for source control management (SCM), collaboration between the globally distributed teams was suffering, preventing them from implementing DevOps.

“Our legacy toolchain was complex, disconnected, and difficult to manage and maintain,” said Eric Labourdette, Head of Global R&D Engineering Services and responsible for worldwide R&D operations including DevOps. “SVN was difficult to administer and didn’t scale, causing extra administrative overhead. It became unmanageable for our team size.”

As the organization looked to move to a microservices architecture and implement DevOps, they needed a solution for SCM that could foster collaboration across locations and projects, and support DevOps practices like continuous integration and automated deploys.

the solution

GitLab for SCM enables DevOps

A modern solution that can be hosted on-premise, GitLab provided a single instance of source code for the entire company. Leveraging a Git-based workflow, Axway’s worldwide R&D teams can now easily share and collaborate on code with nearly zero downtime and minimal administrative overhead. Leveraging the most robust Lightweight Directory Access Protocol (LDAP) support of any SCM provider, with GitLab, Axway is able to manage access and permissions for 600 enterprise developers securely and consistently.

“GitLab offered the most advanced feature set on the market.”

Eric Labourdette

Head of Global R&D Engineering Services

“GitLab met our requirements and gave us the best value for the price,” said Labourdette. “The feature set with GitLab on-premise was more advanced than GitHub and we saw the pace and development [of GitLab] moving faster with a community that was active in delivering and contributing.”

Collaboration between development and operations teams improved, too. Using GitLab’s Jenkins integration, developers can trigger their own builds and see the output of the pipeline status in the same view as their code within GitLab.

“All of the development we have done starts with central source code management in GitLab. This is followed with ephemeral Jenkins through GitLab CI to “eat our own dog food” in creating pipelines that build and deploy images then QA them and execute a security scan. Immutable infrastructure and common continuous deployment using Artifactory and Bintray repositories allows us to deploy Docker container images into AWS. Our new development is based on microservices, Docker on Kubernetes with GitLab being the source of our DevOps pipelines,” Labourdette explains.

the results

Faster release cycles and soaring adoption

Now, with developers empowered to self-serve with minimal guidelines, the DevOps teams at Axway have improved their release cycle time from annual releases down to two weeks for some products.

In using a bottom-up approach to choose their SCM solution, adoption of GitLab was unsurprisingly fast and natural. In just one year, 630 users were onboarded and 3,000 projects were migrated. “Everyone was asking for it,” said Labourdette. “Now, every single developer is running on GitLab without enforcement.”

All information and persons involved in case study are accurate at the time of publication.

August 15, 2020
Upcoming Event: GitLab Commit Virtual 2020
For the first time ever, GitLab’s annual user conference will take place in a virtual environment on Aug. 26, bringing together DevOps luminaries from around the globe for a free, interactive learning experience.

GitLab Commit Virtual is a 24-hour virtual event that provides attendees with the opportunity to join DevOps discussions, demos and presentations, and network with thought leaders from the industry’s top companies, such as Microsoft, Google, Hubspot, Forrester and many more.

Speakers will showcase the power of community and share DevOps best practices through strategy and technology discussions, lessons learned, behind-the-scenes looks at the development life cycle and more.

The agenda for GitLab Commit Virtual features a mix of topics, including technical sessions, live coding, deep-dives and case studies covering DevSecOps, containers, Kubernetes, CI/CD, open source, all-remote and more.

The virtual environment features a lobby, an expo hall lined with booths full of downloadable resources and an auditorium where attendees can watch sessions by industry leaders.

This year’s GitLab Commit features more than 40 sessions from some of the most brilliant DevOps experts, including:
- “DevOps Works! Why Hasn’t Security Kept Up?,” a keynote session by Joni Klippert, StackHawk.
- “DevSecOps in Government and Highly-Regulated Industries,” a keynote session by Nicolas Chaillan, U.S. Air Force.
- “Real World DevOps,” by Abel Wang, Microsoft.
- “Why Your Organization Should Embrace the Community Model,” by Karl Cardenas, State Farm.
- “Getting Fuzzy: Blurring the Lines of Traditional QA and Security Testing,” by David DeSantos and Sam Kerr, GitLab.
- “How the U.S. Army Cyber School Created ‘Courseware as Code’ with GitLab,” by Ben Allison, U.S. Army Cyber School.
- “Measuring DevOps,” by Nathen Harvey and Dina Graves Portman, Google.
- “How To Create an Equitable and Inclusive Culture That Transcends Physical Walls,” by Eimear Marrinan and Meaghan Williams, HubSpot.
By visiting the expo hall, attendees will also be able to interact with sponsors, including AWS, Google Cloud, Lightstep, HashiCorp, Red Hat, VMWare Tanzu and WhiteSource.

Attendees will get a deep dive into how enterprises are transforming DevOps at an organizational level and how they can implement similar practices in their own organization.

To see the full agenda and to register, please visit the GitLab Commit Virtual website.
August 4, 2020
GitLab Releases Massive Update to CI/CD Platform

GitLab has updated its continuous integration/continuous delivery (CI/CD) platform with a raft of capabilities spanning everything from value stream management to cybersecurity.

In addition, GitLab announced it is making generally available Gitaly Clusters, which enable DevOps teams to create a warm replica of a Git repository.

Brendan O’Leary, senior developer evangelist at GitLab, said with release 13 GitLab continues to build on a single code base that allows the platform to be managed and accessed as an integrated set of applications rather than disparate components that DevOps teams need to pull together and then manage.

In terms of core DevOps capabilities, the latest release adds the ability to customize the Value Stream Analytics module to specific workflows. GitLab is also planning to make it possible to visualize stages of a workflow.

GitLab is also improving traceability between requirements and has added the ability to visualize the workflow associated with a specific release. A future release will enable DevOps teams to employ feature flags to conduct both A/B testing based as well as create feature flags from merge requests and to filter feature flags by status, according to the company.

Other capabilities added include more customizable dashboards, with security dashboards now being shareable outside of GitLab to foster collaboration with IT security teams. Future releases will add Kubernetes Clusters to the dashboard to show all clusters and pods in use.

DevOps teams now can route existing monitoring alerts to GitLab for triage and incident resolution. At the same time, GitLab has moved design management to the core platform.

GitLab is also now making AutoDevOps, which provides pre-defined CI/CD pipelines, available on Amazon Web Services (AWS).

In terms of cybersecurity, GitLab has revamped the way the platform manages vulnerabilities to make it easier in a future update to prioritize remediation efforts.

GitLab also has static application security testing (SAST) support for .NET frameworks and has expanded support for offline environments. There’s also now support for dynamic application security testing (DAST) for REST application programming interfaces (APIs) and access to full commit history scan for secrets. Fuzz testing support will be introduced later this year, according to the company, along with an ability to secure secrets across services. GitLab also plans to add integration with security tools that track container behavior analytics, as well as an out-of-the-box container network policy.

Thanks to GitLab’s collaboration with Okta, there is now also tighter integration with Okta’s System for Cross-domain Identity Management, which can be provisioned for a GitLab group.

In terms of compliance, GitLab also plans to enable DevOps teams to establish a compliance framework, adopt its regulatory controls and simplify audit reporting. The company is also working on an initial security policy user interface to simplify setting up security guardrails.

Finally, GitLab has become a Common Vulnerabilities and Exposures (CVE) ID Numbering Authority (CNA). GitLab users can request a CVE from GitLab, either for GitLab itself or for any project hosted on GitLab.com. In the future, users can request CVE IDs directly from within GitLab.

O’Leary said GitLab is working toward increasing developer confidence in their security skills. By making it easier to embrace best DevOps practices, developers no longer will have to tiptoe around security issues that they today largely have little to no familiarity with, he said.

In general, O’Leary said GitLab’s biggest challenge is getting organizations to move beyond simply using it to manage source code. Once organizations do make their first foray beyond source code management, however, it’s not too long before they are employing a wide range of modules, he noted.

Of course, encouraging organizations to dive deeper DevOps has as much to do with the culture of the organization as it does the capabilities of the CI/CD platform employed.

May 26, 2020
GitLab Survey Sees DevOps Gains as Developers Exercise More Control

A global survey of 3,650 software professionals published by GitLab respondents indicates developers are exercising more direct control over IT environments.

More than a third of respondents (35%) said developers define and/or create the infrastructure their applications run on, with 14% actually monitoring and responding to infrastructure events. Additionally, 18% of developers instrument code for production monitoring, while 12% serve as an escalation point when there are incidents.

More than 25% of developers reported feeling solely responsible for security, while 33% of security team members say they own security. A total of 29% said they believe everyone should be responsible for security.

A quarter of respondents said their organizations have been practicing DevOps for three to five years, while 37% said they have been practicing for one to three years. Nearly 60% of respondents said their organizations deploy code either multiple times a day, once a day or once every few days, a 15% increase over the previous year.

Brendan O’Leary, senior developer evangelist for GitLab, said that massive jump in the number of organizations capable of deploying code at faster rates indicates many more organizations are starting to move further along the DevOps maturity curve. For example, the survey finds 70% of developers can now provision their own IT environments.

Well over a third of respondents (38%) said their DevOps implementations include a continuous integration/continuous delivery (CI/CD) platform. Almost 59% of those surveyed use GitLab, while 23% use GitHub and 11% use BitBucket. For builds, 60% use GitLab and 38% use Jenkins. A total of 29% said their DevOps implementations include test automation, while 16% said they have embraced DevSecOps.

Almost 40% of survey takers said they “partially” use microservices, while a quarter (26%) said they fully use them. Well over a third (38%) have also adopted Kubernetes.

Despite that progress, however, the survey makes it clear there is still much work to be done. More than 42% said testing still happens too late in the life cycle. In fact, 47% identified testing as the top DevOps bottleneck for the second year in a row. Only 12% said they have completely automated testing.

When it comes to security, well over a third (36%) find it hard to understand, process and fix any discovered vulnerabilities. About a third (31%) said prioritizing vulnerability remediation is still an uphill battle.

O’Leary said when it comes to security the most challenging issue remains determining what vulnerabilities to prioritize alongside a long list of other bugs and issues that often need to be addressed. Cybersecurity teams all too often continue to send developers a list of vulnerabilities they have discovered with no context, he noted. Many developers are only made aware of an issue after their code has been merged, which O’Leary said makes it more difficult for them to address a specific security issue.

It’s not clear any organization will ever achieve complete DevOps nirvana. However, as organizations become more proficient it’s clear the return on investment in DevOps is starting to be achieved as more organizations deliver code faster. The challenge now, of course, is making sure the right secure code is delivered at the right time.

May 18, 2020
GitLab Responds To GitHub Making Teams Free – We All Win

Microsoft’s GitHub recently announced that it was going to make a change to its product lineup by making the team version of GitHub free and lowering the price on a full-featured version. The move seemed aimed squarely at matching GitLab’s offering. Well, now GitLab has responded to GitHub.

While both of these excellent offerings compete to bring the best product to market, the real winners here are all of us. True market dynamics are at play resulting in both GitLab and GitHub lowering prices and adding more features (and not just GitHub and GitLab but also their competitors, including Atlassian among others).

I had a chance to sit down with Sid Sijbrandij to discuss GitHub’s move, what GitLab will do and what this means for the market. (BTW, I have to apologize to Sid—it seems I have been mispronouncing his name for years and he is too much of a gentleman to correct me. The proper pronunciation of his name is “See Brandy.”) The video of our conversation appears below, and a blog on the GitLab site explains it all.

In our interview, Sid was very clear that GitLab owes a huge amount of gratitude to GitHub, as it was GitHub that spurred on the early development of GitLab. He truly respects what GitHub has done, as well as the great job Microsoft has done since acquiring GitHub.

The GitLab blog post lays out very clearly what the GitHub offering is and how it compares to the GitLab offering. It’s no coincidence that the new GitHub paid teams offering is the same price as the GitLab bronze offering.

Price aside, according to Sid, the real advantage of GitLab is that its vision of an end-to-end total DevOps solution and the features it adds to achieve this vision give GitLab customers more than they can get from GitHub. While I agree that is true today, I don’t think GitHub is going to be content with its current lineup for long. I think the Microsoft entity already envisions a total DevOps solution as being part of GitHub’s future.

On top of that, I think GitHub and Microsoft are already thinking of how they can leverage Azure to give GitHub an advantage. To Microsoft’s credit, though, at least until now there has not been any special advantage of using GitHub with Azure. Azure remains an open platform that all vendors seem to get fair access to and support from.

All of this aside though, we are all the real winners here. What a great time to be a developer/DevOps professional. While GitLab and GitHub compete with each other to bring more features to market for less money, as I mentioned other companies are competing to bring end-to-end DevOps solutions to market as well. We benefit from all of this competition by getting better tools and solutions at better prices. That’s true market dynamics at work.

It should get only better in the months and years ahead as well. In spite of COVID19 and the rest, it is a great time to be alive.

— Alan Shimel

April 15, 2020
2nd Watch Allies With GitLab for Managed DevOps Service

2nd Watch today launched a managed DevOps service based on the continuous integration/continuous deployment (CI/CD) platform from GitLab that it will operate on behalf of customers in addition to coaching them on how to adopt best DevOps practices.

Stefana Muller, a senior product manager, said the 2nd Watch Managed DevOps service combines the managed and professional services capabilities of 2nd Watch into a single offering. That approach is required because when it comes to DevOps most organizations need as much help transitioning their culture as they will operating their CI/CD environment, she said.

One of the major challenges organizations face when trying to embrace DevOps is they typically spend a lot of money upfront only to see those efforts flounder when changing the internal culture of the organization becomes too difficult, Muller said. As part of an effort to smooth that transition, 2nd Watch DevOps experts will assess an organization’s readiness to adopt DevOps tools and processes and then train internal teams on DevOps fundamentals such as managing infrastructure as code and Git principles. The assessment is based on a Culture, Automation, Lean Practices, Measurement and Sharing (CALMS) methodology.

The 2nd Watch service is built around an on-premises edition of the GitLab CI/CD platform that it will host and upgrade on behalf of a customer on either an Amazon Web Services (AWS) or Microsoft public cloud platform. The DevOps service will focus on enabling organizations to build both monolithic and microservices-based applications faster because no organization today has fully transitioned to microservices. The company already provides a managed Kubernetes service for building and deploying applications based on a microservices architecture.

2nd Watch chose to partner with GitLab because of the completeness of that CI/CD platform, which among other things includes integrated security modules that can be employed to advance DevSecOps practices as well, Muller said, noting that longer-term, 2nd Watch is planning to layer a more robust set of managed DevSecOps services on top of the GitLab platform.

Managed DevOps offerings are starting to proliferate as the number of services providers that have attained certifications from multiple IT vendors has increased. It’s not clear to what degree organizations will prefer to rely on these services just yet. However, it’s is apparent many organizations are trying to shift as much of their limited resources to building application code versus managing IT infrastructure. It’s also possible that as the COVID-19 coronavirus pandemic becomes more widespread many organizations will need to rely on external service providers to manage their DevOps environments.

Regardless of the motivation, organizations that are at the beginning of their DevOps journey clearly will need more help than those that are further along the DevOps maturity curve. The decision most organizations will need to make is to what degree will they rely on a managed DevOps service to accelerate their transition versus opting to rely permanently on an external IT service provider to manage one of their most critical IT environments.

— Mike Vizard

March 19, 2020
GitLab Updates Core CI/CD Platform

GitLab this week delivered an update to its namesake continuous integration/continuous delivery platform that promises to make pipelines more efficient and easier to manage, in addition to making it easier to set up pipelines in Windows environments.

Version 12.7 of the core GitLab platform adds support for Parent-Child Pipelines and Pipeline Resource Groups. Parent-Child Pipelines make it possible to run separate child pipelines concurrently, while Pipeline Resource Groups enable DevOps teams to limit pipeline concurrency to better manage jobs and resources.

A Code Review Analytics module is designed to make it easier to find Merge Requests in review that require some level of intervention, while enhanced Merge Request widgets show when changes have made it to a specific environment.

Other new capabilities include being able to automatically stage all changes with the GitLab integrated development environment (IDE) and the ability to share group access with another group.

Finally, GitLab has added a beta release of Windows Shared Runner, which brings Windows environments to the GitLab platform via a managed service. Darren Eastman, senior product manager for Runner at GitLab, said instead of having to separately download agent software through which jobs on a GitLab pipeline are executed, Windows environments are becoming full-fledged citizens of the GitLab platform.

Eastman said IT organizations running Windows compared to their Linux brethren are still playing a little catch-up in terms of DevOps maturity. However, with the arrival of microservices based on Docker containers on Windows, the need to embrace best DevOps practices to manage application development and deployment is becoming more apparent, he said.

Of course, Microsoft is pushing its own rival CI/CD platform in the form of Azure DevOps, formerly known as Visual Team Studios. GitLab is betting that most organizations will prefer to consume a fully managed CI/CD service that spans both Windows and Linux platforms, especially as hybrid cloud computing gains traction in the months and years ahead.

Regardless of the CI/CD platform employed, the overall size of the DevOps community should expand considerably in 2020 as more organizations that rely on Windows to build and deploy applications embrace DevOps’ core principles. Naturally, competition between Microsoft and providers of rival CI/CD platforms will be fierce. Microsoft in many ways is a behemoth that was constructed mainly by a loyal base of developers that the company can be expected to guard jealously. However, as Microsoft has embraced Linux alongside Windows in the cloud, the number of Windows developers who have been exposed to alternative platforms has increased.

In the meantime, organizations that have teams that build and deploy applications on both Windows and Linux will have some cultural challenges to overcome should they decide to standardize on a common set of DevOps processes. Rather than managing each platform in isolation, there’s a clear opportunity to reduce costs and increase application development efficiency. The issue now is determining which DevOps platform might best enable them to begin a journey that is likely to take a few years to fully complete.

— Mike Vizard

January 24, 2020
WhiteSource Enhances GitLab Integration with Support for GitLab Ultimate

Adding to WhiteSource’s existing GitLab integration, the enhancement will help programmers detect and remediate vulnerable code earlier without leaving the GitLab CI/CD pipeline

San Francisco – January 14, 2020 – WhiteSource, the leader in open source security and license compliance management, announced today enhanced GitLab integration for the company’s developer-focused offering, WhiteSource for Developers. This enhancement adds to WhiteSource’s existing GitLab integration, giving developers alerts on open source components with known vulnerabilities earlier in the software development lifecycle, and providing clear, actionable remediation suggestions before the code ever leaves their hands. With support for the GitLab Security Dashboard, a capability available for GitLab Ultimate users, security pros can gain visibility into unresolved vulnerabilities earlier than ever and GitLab users can gain additional insight from WhiteSource.

“With this new integration, developers can more easily find and fix vulnerable code without leaving the GitLab CI/CD pipeline,” said David Habusha, VP Product Management at WhiteSource, “while security professionals can leverage their WhiteSource investment to advance their shift left and further automate risk policies within the Software Development Lifecycle (SDLC).”

“We are excited to have WhiteSource as a part of GitLab’s partner program to complement our security capabilities,” said Brandon Jung, VP of Alliances at GitLab. “GitLab gives customers earlier visibility to software vulnerabilities and actionable remediation. This integration furthers our commitment to provide our customers a seamless DevSecOps experience.”

WhiteSource integration with GitLab is available with WhiteSource for Developers. Additional information regarding this integration can be found here.

About WhiteSource

WhiteSource is the leader in continuous open source security and license compliance management. Its vision is to empower businesses to develop better software by harnessing the power of open source. Industry leaders like Microsoft, IBM, and hundreds more trust WhiteSource to secure and manage the open source components in their software. For more information, please visit www.whitesourcesoftware.com

January 14, 2020