You are here

Agreguesi i feed

Riccardo Padovani: A generic introduction to Gitlab CI

Planet Ubuntu - Mar, 28/11/2017 - 10:00md

At fleetster we have our own instance of Gitlab and we rely a lot on Gitlab CI. Also our designers and QA guys use (and love) it, thanks to its advanced features.

Gitlab CI is a very powerful system of Continuous Integration, with a lot of different features, and with every new releases, new features land. It has a very rich technical documentation, but it lacks a generic introduction for whom want to use it in an already existing setup. A designer or a tester doesn’t need to know how to autoscale it with Kubernetes or the difference between an image or a service.

But still, he needs to know what is a pipeline, and how to see a branch deployed to an environment. In this article therefore I will try to cover as many features as possible, highlighting how the end users can enjoy them; in the last months I explained such features to some members of our team, also developers: not everyone knows what Continuous Integration is or has used Gitlab CI in a previous job.

If you want to know why Continuous Integration is important I suggest to read this article, while for finding the reasons for using Gitlab CI specifically, I leave the job to Gitlab.com itself.

Introduction

Every time a developer changes some code he saves his changes in a commit. He can then push that commit to Gitlab, so other developers can review the code.

Gitlab will also start some work on that commit, if the Gitlab CI has been configured. This work is executed by a runner. A runner is basically a server (it can be a lot of different things, also your PC, but we can simplify it as a server) that executes instructions listed in the .gitlab-ci.yml file, and reports the result back to Gitlab itself, which will show it in his graphical interface.

When a developer has finished implementing a new feature or a bugfix (activity that usual requires multiple commits), can open a merge request, where other member of the team can comment on the code and on the implementation.

As we will see, also designers and testers can (and really should!) join this process, giving feedbacks and suggesting improvements, especially thanks to two features of Gitlab CI: environments and artifacts.

Pipelines

Every commit that is pushed to Gitlab generates a pipeline attached to that commit. If multiple commits are pushed together the pipeline will be created only for the last of them. A pipeline is a collection of jobs split in different stages.

All the jobs in the same stage run in concurrency (if there are enough runners) and the next stage begins only if all the jobs from the previous stage have finished with success.

As soon as a job fails, the entire pipeline fails. There is an exception for this, as we will see below: if a job is marked as manual, then a failure will not make the pipeline fails.

The stages are just a logic division between batches of jobs, where doesn’t make sense to execute next jobs if the previous failed. We can have a build stage, where all the jobs to build the application are executed, and a deploy stage, where the build application is deployed. Doesn’t make much sense to deploy something that failed to build, does it?

Every job shouldn’t have any dependency with any other job in the same stage, while they can expect results by jobs from a previous stage.

Let’s see how Gitlab shows information about stages and stages’ status.

Jobs

A job is a collection of instructions that a runner has to execute. You can see in real time what’s the output of the job, so developers can understand why a job fails.

A job can be automatic, so it starts automatically when a commit is pushed, or manual. A manual job has to be triggered by someone manually. Can be useful, for example, to automatize a deploy, but still to deploy only when someone manually approves it. There is a way to limit who can run a job, so only trustworthy people can deploy, to continue the example before.

A job can also build artifacts that users can download, like it creates an APK you can download and test on your device; in this way both designers and testers can download an application and test it without having to ask for help to developers.

Other than creating artifacts, a job can deploy an environment, usually reachable by an URL, where users can test the commit.

Job status are the same as stages status: indeed stages inherit theirs status from the jobs.

Artifacts

As we said, a job can create an artifact that users can download to test. It can be anything, like an application for Windows, an image generated by a PC, or an APK for Android.

So you are a designer, and the merge request has been assigned to you: you need to validate the implementation of the new design!

But how to do that?

You need to open the merge request, and download the artifact, as shown in the figure.

Every pipeline collects all the artifacts from all the jobs, and every job can have multiple artifacts. When you click on the download button, it will appear a dropdown where you can select which artifact you want. After the review, you can leave a comment on the MR.

You can always download the artifacts also from pipelines that do not have a merge request open ;-)

I am focusing on merge request because usually is where testers, designer, and shareholder in general enter the workflow.

But merge requests are not linked to pipelines: while they integrate nice one in the other, they do not have any relation.

Environments

In a similar way, a job can deploy something to an external server, so you can reach it through the merge request itself.

As you can see the environment has a name and a link. Just clicking the link you to go to a deployed version of your application (of course, if your team has setup it correctly).

You can click also on the name of the environment, because Gitlab has also other cool features for environments, like monitoring.

Conclusion

This was a small introduction to some of the features of Gitlab CI: it is very powerful, and using it in the right way allows all the team to use just one tool to go from planning to deploying. A lot of new features are introduced every month, so keep an eye on the Gitlab blog.

For setting it up, or for more advanced features, take a look to the documentation.

In fleetster we use it not only for running tests, but also for having automatic versioning of the software and automatic deploys to testing environments. We have automatized other jobs as well (building apps and publish them on the Play Store and so on).

Speaking of which, do you want to work in a young and dynamically office with me and a lot of other amazing guys? Take a look to the open positions at fleetster!

Kudos to the Gitlab team (and others guys who help in their free time) for their awesome work!

If you have any question or feedback about this blog post, please drop me an email at riccardo@rpadovani.com or tweet me :-) Feel free to suggest me to add something, or to rephrase paragraphs in a clearer way (English is not my mother tongue).

Bye for now,
R.

P.S: if you have found this article helpful and you’d like we write others, do you mind to help us reaching the Ballmer’s peak and buy me a beer?

Sebastian Kügler: KDE’s Goal: Privacy

Planet Ubuntu - Mar, 28/11/2017 - 8:29md

by BanksyAt Akademy 2016, the KDE community started a long-term project to invigorate its development (both, technically and organizationally) with more focus. This process of soul-searching has already yielded some very useful results, the most important one so far being agreement of a common community-wide vision:

A world in which everyone has control over their digital life and enjoys freedom and privacy.

This presents a very high-level vision, so a logical follow-up question has been how this influences KDE’s activities and actions in practice. KDE, being a fairly loose community with many separate sub-communities and products, is not an easy target to align to a common goal. A common goal may have very different on each of KDE’s products, for an email and groupware client, that may be very straight-forward (e.g. support high-end crypto, work very well with privacy-respecting and/or self-hosted services), for others, it may be mostly irrelevant (a natural painting app such as Krita simply doesn’t have a lot of privacy exposure), yet for a product such as Plasma, the implications may be fundamental and varied.
So in the pursuit of the common ground and a common goal, we had to concentrate on what unites us. There’s of course Software Freedom, but that is somewhat vague as well, and also it’s already entrenched in KDE’s DNA. It’s not a very useful goal since it doesn’t give us something to strive for, but something we maintain anyway. A “good goal” has to be more specific, yet it should have a clear connection to Free Software, since that is probably the single most important thing that unites us. Almost two years ago, I posed that privacy is Free Software’s new milestone, trying to set a new goal post for us to head for. Now the point where these streams join has come, and KDE has chosen privacy as one of its primary goals for the next 3 to 4 years. The full proposal can be read here.
“In 5 years, KDE software enables and promotes privacy”

Privacy, being a vague concept, especially given the diversity in the KDE community needs some explanation, some operationalization to make it specific and to know how we can create software that enables privacy. There are three general focus areas we will concentrate on: Security, privacy-respecting defaults and offering the right tools in the first place.

Security

Improving security means improving our processes to make it easier to spot and fix security problems and avoiding single points of failure in both software and development processes. This entails code review, quick turnaround times for security fixes.

Privacy-respecting defaults

Defaulting to encrypted connections where possible and storing sensible data in a secure way. The user should be able to expect the KDE software Does The Right Thing and protect his or her data in the best possible way. Surprises should be avoided as much as possible, and reasonable expectations should be met with best effort.

Offering the right tools

KDE prides itself for providing a very wide range of useful software. From a privacy point of view, some functions are more important than others, of course. We want to offer the tools that most users need in a way that allows them to lead their life privately, so the toolset needs to be comprehensive and cover as many needs as possible. The tools itself should make it easy and straight-forward to achieve privacy. Some examples:

  • An email client allowing encrypted communication
  • Chat and instant messenging with state-of-the art protocol security
  • Support for online services that can be operated as private instance, not depending on a 3rd party provider

Of course, this is only a small part, and the needs of our userbase varies wildly.

Onwards from here…

In the past, KDE software has come a long way in providing privacy tools, but the tool-set is neither comprehensive, nor is privacy its implications widely seen as critical to our success in this area. Setting privacy as a central goal for KDE means that we will put more focus on this topic and lead to improved tools that allow users to increase their level of privacy. Moreover, it will set an example for others to follow and hopefully increase standards across the whole software ecosystem. There is much work to do, and we’re excited to put our shoulder under it and work on it.

Jono Bacon: WeWork to Aquire Meetup.com: Some Thoughts

Planet Ubuntu - Mar, 28/11/2017 - 7:30pd

Rumors are abound that WeWork are to acquire Meetup.com for $30 million. I wanted to share a few thoughts here. The caveat: I have no behind-the-scenes knowledge here, these are just some thoughts based on a somewhat cursory knowledge of both organizations. This is also (currently) speculation, so the nature and numbers of an acquisition might be different.

It is unsurprising that WeWork would explore Meetup.com for an acquisition. From merely a lead-generation perspective, making it simple for the hundreds of thousands of meetups around the world to easily host their events at WeWork spaces will undoubtedly have a knock-on effect of people registering as WeWork members, either as individual entrepreneurs, or hiring hosted office space for their startups.

Some of the biggest hurdles for meetups are (a) sourcing sponsorship funds to cover costs, and (b) facilitating the target of those very costs such as food/beverage, AV/equipment, and promotional costs/collateral. WeWork could obviously provide not just space and equipment but also potentially broker sponsorships too. As with all ecosystem-to-ecosystem acquisitions, bridging those ecosystems exposes value (e.g. Facebook and Instagram.)

The somewhat surprising element here to me is the $30 million valuation. Meetup.com used to publish their growth stats, but it seems they are not there any more. The most recent stats I could find (from 2012 on Quora) suggested 11.1 million users and 349,000+ meetups. There is a clear source of revenue here, and while it may be relatively limited in potential growth, I would have expected the revenue projection, brand recognition, and current market lead would be worth more than $30 million.

Mind you, and with the greatest of respect to the wonderful people at Meetup.com, I feel they have somewhat missed the mark in terms of their potential for innovation. There are all kinds of things they could have done to capitalize on their market position by breaking down the onboarding and lifecycle of a meetup (from new formation to regular events) and optimizing and simplifying every element of this for organizations.

There are all kinds of services models that could have been hooked in here such as partnerships with providers (e.g. food, equipment, merch etc) and partner organizations (e.g. major potential consumers and sponsors of the service), and more. I also think they could have built out the profile elements of their service to glue different online profiles together (e.g. GitHub, LinkedIn, Reddit) to not just source groups, but to become a social platform that doesn’t just connect you to neat groups, but to neat people too.

As I have been saying for a while, there is also a huge missed opportunity in converting the somewhat transitory nature of a meetup (you go along and have a good time, but after the meetup finishes, nothing happens) into a broader and more consistently connected set of engagements between members. Doing this well requires community building and collaboration experience, that I would proffer, most Meetup.com organizers probably don’t have.

All of this seems like a bit of a missed opportunity, but as someone sitting on the outside of the organization, who am I to judge? Running a popular brand and service is a lot of work, and from what I understand, they have a fairly small team. There is only so much you can do.

My suspicion is that Meetup.com were shopping around a little for a sale and prospective buyers were primarily interested in their brand potential and integration (with an expected limited cap on revenues). As such, $30 million might make sense, and would strike me as a steal for WeWork.

Either way, congratulations to WeWork and Meetup.com in their future partnership.

The post WeWork to Aquire Meetup.com: Some Thoughts appeared first on Jono Bacon.

Faqet

Subscribe to AlbLinux agreguesi