GitLab

Continuous Integration/Continuous Development with FOSS Tools

Quentin Hartman — Wed, 31 Jul 2019 11:30:00 +0000

Up your DevOps game! Get the fundamentals of CI/CD with FOSS tools now!

One of the hottest topics within the DevOps space is Continuous Integration and Continuous Deployment (CI/CD). This attention has drawn lots of investment dollars, and a vast array of proprietary Software As A Service (SaaS) tools have been created in the CI/CD space, which traditionally has been dominated by free open-source software (FOSS) tools. Is FOSS still the right choice with the low cost of many of these SaaS options?

It depends. In many cases, the cost of self-hosting these FOSS tools will be greater than the cost to use a non-FOSS SaaS option. However, even in today's cloud-centric and SaaS-saturated world, you may have good reasons to self-host FOSS. Whatever those reasons may be, just don't forget that "Free" isn't free when it comes to keeping a service running reliably 24/7/365. If you're looking at FOSS as a means to save money, make sure you account for those costs.

Even with those costs accounted for, FOSS still delivers a lot of value, especially to small and medium-sized organizations that are taking their first steps into DevOps and CI/CD. Starting with a commercialized FOSS product is a great middle ground. It gives a smooth growth path into the more advanced proprietary features, allowing you to pay for those only once you need them. Often called Open Core, this approach isn't universally loved, but when applied well, it has allowed for a lot of value to be created for everyone involved.

An Embarrassment of Riches

The DevOps concept exploded in the past several years. The term quickly saturated the mainstream technology industry. With this increased mindshare comes a corresponding increase in the number of tools available to accomplish DevOps-related tasks. That's a blessing and a curse as a DevOps practitioner. Thanks to the endless buffet of options, you're sure to find something that meets your needs, but to a newcomer, the multitude of choices is overwhelming. Combine that with the vast scope of tasks that fall under the DevOps umbrella and the competing claims of "best" from all sides, and you have a recipe for paralysis. A good place for finding tools and filtering by a variety of criteria is DevOpsBookmarks.com. The content is all open source, and the maintainers are diligent about merging contributions, but it hasn't seen a lot of updates lately. Despite that, it makes a great jumping off point. If you find something noteworthy that should be included, a pull request would be appreciated!

Go to Full Article

Take Your Git In-House

John S. Tonello — Thu, 27 Sep 2018 12:56:39 +0000

by John S. Tonello

If you're wary of the Microsoft takeover of GitHub, or if you've been looking for a way to ween yourself off free public repositories, or if you want to ramp up your DevOps efforts, now's a good time to look at installing and running GitLab yourself. It's not as difficult as you might think, and the free, open-source GitLab CE version provides a lot of flexibility to start from scratch, migrate or graduate to more full-fledged versions.

In today's software business, getting solid code out the door fast is a must, and practices to make that easier are part of any organization's DevOps toolset. Git has risen to the top of the heap of version control tools, because it's simple, fast and makes collaboration easy.

For developers, tools like Git ensure that their code isn't just backed up and made available to others, but nearly guarantees that it can be incorporated into a wide variety of third-party development tools—from Jenkins to Visual Studio—that make continuous integration and continuous delivery (CI/CD) possible. Orchestration, automation and deployment tools easily integrate with Git as well, which means code developed on any laptop or workstation anywhere can be merged, branched and integrated into deployed software. That's why version control repositories are the future of software development and DevOps, no matter how big or small you are, and no matter whether you're building monolithic apps or containerized ones.

Getting Started with Git

Git works by taking snapshots of code on every commit, so every version of contributed code is always available. That means it's easy to roll back changes or look over different contributors' work.

If you're working in an environment that uses Git, you can do your work even when you're offline. Everything is saved in a project structure on your workstation, just as it is in the remote Git repository, and when you're next online, your commits and pushes update the master (or other) code branch quickly and easily.

Most Git users (even newbies) use the Git command-line tools to clone, commit and push changes, because it's easy, and for nearly 28-million developers, GitHub has become the de facto remote Git-based repository for their work. In fact, GitHub has moved beyond being just a code repository to become a multifaceted code community featuring 85-million projects. That's a lot of code.

GitLab is gaining popularity as a remote code repository too, but it's smaller and bills itself as more DevOps-focused, with CI/CD tool included for free. Both repositories offer free hosted accounts that allow users to create a namespace, and start contributing and collaborating right away. The graphical browser interfaces offered by the GitHub- and GitLab-hosted services make it easy to manage projects and project code, and also to add SSH keys, so you easily can connect from your remote terminal on Linux, Windows or Mac.

Go to Full Article

Opinion: GitHub vs GitLab

Matt Lee — Mon, 16 Jul 2018 11:30:00 +0000

by Matt Lee

Free software deserves free tools, not Microsoft-owned GitHub.

So, Microsoft bought GitHub, and many people are confused or worried. It's not a new phenomenon when any large company buys any smaller company, and people are right to be worried, although I argue that their timing is wrong. Like Microsoft, GitHub has made some useful contributions to free and open-source software, but let's not forget that GitHub's main product is proprietary software. And, it's not just some innocuous web service either; GitHub makes and sells a proprietary software package you can download and run on your own server called GitHub Enterprise (GHE).

Let's remember how we got here. BitMover made a tool called BitKeeper, a proprietary version control system that allowed free-of-charge licenses to free software projects. In 2002, the Linux kernel switched to using BitKeeper for its version control, although some notable developers made the noble choice to refuse to use the proprietary program. Many others did not, and for a number of years, kernel development was hampered by BitKeeper's restrictive noncommercial licenses.

In 2005, Andrew Tridgell, working at OSDL, developed a client that bypassed this restriction, and as a result, BitMover removed licenses to BitKeeper from all OSDL employees—including Linus Torvalds. Eventually, all non-commercial licenses were stopped, and new licenses included clauses preventing the development of alternative version control systems. As a result of this, two new projects were born: Mercurial and Git. Created in a few short weeks in 2005, Git quickly became the version control system for Linux development.

Proprietary version control tools aren't common in free software development, but proprietary collaboration websites have been around for some time. One of the earliest collaboration websites still around today is Sourceforge. Sourceforge was created in the late 1990s by VA Software, and the code behind the project was released in 2000.

Quickly this situation changed, and the project was shuttered and then became Sourceforge Enterprise Edition, a proprietary software package. The code that ran Sourceforge was forked into GNU Savannah (later Savane) and GForge, and it's still use today by both the GNU Project and CERN. When I last wrote about this problem, almost exactly ten years ago, Canonical's ambitious Launchpad service still was proprietary, something later remedied in 2009. Gitorious was created in 2010 and was for a number of years the Git hosting platform for the discerning free software developer, as the code for Gitorious was fully public and licensed under favorable terms for the new wave of AGPL-licensed projects that followed the FSF's Franklin Street Statement. Gitorious, also, is sadly no longer with us.

Go to Full Article

Git Your July 2018 Issue of Linux Journal: Now Available

Carlie Fairchild — Mon, 02 Jul 2018 17:30:00 +0000

by Carlie Fairchild

Along with Microsoft buying Github recently, we received hundreds of questions and comments about all things git. How does one install and run GitLab themselves? Should they? What's the difference between GitHub and GitLab? How can one migrate repositories from GitHub and host on their own Linux server? So with this July issue of Linux Journal, we take a Deep Dive in to... git. Enjoy!

Feature articles include:

A Git Origin Story by Zack Brown

A look at the Linux kernel developers' various revision control solutions through the years, Linus Torvalds' decision to use BitKeeper and the controversy that followed, and how Git came to be created.

Git Quick Start Guide by Patrick Whelan

Ditch USBs and start using real version control, and if you follow this guide, you can start using git in 30 minutes!

Building a Bare-Bones Git Environment by Andy Carlson

How to migrate repositories from GitHub, configure the software and get started with hosting Git repositories on your own Linux server.

Take Your Git In-House by John S. Tonello

Terrible Ideas in Git by Corey Quinn

This article was derived from a talk that GitHub Universe faithfully rejects every year. I can't understand why....

Opinion: GitHub vs GitLab by Matt Lee

Free software deserves free tools, not Microsoft-owned GitHub.

Other articles in this issue:

Encrypting NFSv4 with Stunnel TLS by Charles Fisher

NFS clients and servers push file traffic over clear-text connections in the default configuration, which is incompatible with sensitive data. TLS can wrap this traffic, finally bringing protocol security. Before you use your cloud provider's NFS tools, review all of your NFS usage and secure it where necessary.

Advertising 3.0 by Doc Searls

Road to RHCA—Preparation Meets Opportunity by Taz Brown

FOSS Project Spotlight: ONLYOFFICE, an Online Office Suite by Tatiana Kochedykova

At Rest Encryption by Kyle Rankin

Progress with Your Image by Kyle Rankin

FOSS Project Spotlight: Pydio Cells, an Enterprise-Focused File-Sharing Solution by Italo Vignoli

Atomic Modeling with GAMGI by Joey Bernard

News Briefs by Jill Franklin

Kyle Rankin's Hack and /: What Really IRCs Me: Slack

Reuven M. Lerner's At the Forge: Introducing Python 3.7's Dataclasses

Go to Full Article

Microsoft Buys GitHub: Three Weeks Later

Marcel Gagné — Tue, 26 Jun 2018 11:30:00 +0000

by Marcel Gagné

I heard that Microsoft would be buying GitHub just a couple days before it happened when Carlie Fairchild at Linux Journal told me about it. I replied to the news with a solid, “Get! Out!” Needless to say, I had my doubts. As someone who remembers all too well the “Embrace, extend and extinguish" days of Microsoft, the news of this latest embrace did, however briefly, bring back those old memories. When I was asked what I thought, I answered that the optics were bad.A lot of years have passed since, back in 2001, Steve Ballmer declared Linux to be a cancer. These days, Microsoft loves Linux. It says so right on its website. Two years ago, Steve Ballmer also proclaimed his love for Linux. In 2018, Microsoft has its own distribution that it uses in its Azure cloud. Microsoft includes several different flavors of Linux in its app store (the Windows Subsystem for Linux), all of which can be installed on Windows 10. Microsoft develops for Linux. Heck, Microsoft even contributes to the Linux kernel.

The reason I felt the optics were bad is that Microsoft has spent the last few years going out of its way to paint itself as a friend to Linux and open source. This, I thought, can only be seen as a bad move. Well, it’s been three weeks, more or less, since the the acquisition became official, to the tune of $7.5 billion US. What happened?

For starters, Jim Zemlin, the Executive Director of the Linux Foundation, praised the Microsoft acquisition of GifHub, suggesting that it could be a good thing for everyone. Former open-source star and the new CEO of GitHub, Nat Friedman, did an AMA on Reddit to reassure developers of open-source software that they had nothing to fear from the new landlords.

Linus Torvalds, the creator of the Linux kernel and git itself, didn’t comment directly, but he has been critical of GitHub in the past, so perhaps it doesn’t change anything for him. Besides, the kernel is primarily housed on a private git server, and GitHub is just a public mirror for the code.

That didn’t stop some number of open-source developers from swearing off GitHub and looking for other places to host their projects. GitLab, a minor competitor to GitHub, seemed poised to be the natural beneficiary of this move. In a Twitter post dated June 3rd, it cited that its GitHub to GitLab conversion rate was running at ten times normal.

Go to Full Article

Back Up GitHub and GitLab Repositories Using Golang

Amit Saha — Mon, 04 Jun 2018 21:46:37 +0000

by Amit Saha

Want to learn Golang and build something useful? Learn how to write a tool to back up your GitHub and GitLab repositories.

GitHub and GitLab are two popular Git repository hosting services that are used to host and manage open-source projects. They also have become an easy way for content creators to be able to invite others to share and collaborate without needing to have their own infrastructure setup.

Using hosted services that you don't manage yourself, however, comes with a downside. Systems fail, services go down and disks crash. Content hosted on remote services can simply vanish. Wouldn't it be nice if you could have an easy way to back up your git repositories periodically into a place you control?

If you follow along with this article, you will write a Golang program to back up git repositories from GitHub and GitLab (including custom GitLab installations). Being familiar with Golang basics will be helpful, but not required. Let's get started!

Hello Golang

The latest stable release of Golang at the time of this writing is 1.8. The package name is usually golang, but if your Linux distro doesn't have this release, you can download the Golang compiler and other tools for Linux. Once downloaded, extract it to /usr/local:


$ sudo tar -C /usr/local -xzf 
$ export PATH=$PATH:/usr/local/go/bin

Opening a new terminal and typing $ go version should show the following:


$ go version
go version go1.8 linux/amd64

Let's write your first program. Listing 1 shows a program that expects a -name flag (or argument) when run and prints a greeting using the specified name. Compile and run the program as follows:


$ go build listing1.go
$ ./listing1 -name "Amit"
Hello Amit

$ ./listing1
./listing1
2017/02/18 22:48:25 Please specify your name using -name
$ echo $?
1

If you don't specify the -name argument, it exits printing a message with a non-zero exit code. You can combine both compiling and running the program using go run:


$ go run listing1.go -name Amit
2017/03/04 23:08:11 Hello Amit

Listing 1. Example Program listing1.go

Go to Full Article