Commit ffbca5f1 authored by Rebecca Dodd's avatar Rebecca Dodd

Change blog post titles to sentence case

parent 5c417fc6
Pipeline #14624315 (#) passed with stages
in 20 minutes
---
title: "Expanding Our Enterprise Offering: Announcing GitLab Enterprise Edition Premium"
title: "Expanding our Enterprise offering: Announcing GitLab Enterprise Edition Premium"
author: Amara Nwaigwe
author_twitter: its_amaracle
categories:
......
---
title: "Git Tips & Tricks"
title: "Git tips and tricks"
author: Achilleas Pipinellis
author_twitter: _axil
categories: git
......
---
title: "Continuous Delivery of a Spring Boot application with GitLab CI and Kubernetes"
title: "Continuous delivery of a Spring Boot application with GitLab CI and Kubernetes"
author: Marco Lenzo
author_twitter: marco_lenzo
categories: GitLab CI
......@@ -8,7 +8,7 @@ description: "Create a Continuous Delivery pipeline to deploy a Spring Boot app
guest: true
---
[Continuous Integration, Continuous Deployment and Continuous Delivery](https://about.gitlab.com/2016/08/05/continuous-integration-delivery-and-deployment-with-gitlab/) are increasingly popular topics among modern development teams. Together they enable a team to build, test and deploy the code at any commit. The main benefit of these approaches is the ability to release more quality code more frequently through the means of automated pipelines. The tough part is building such pipelines. There is a myriad of tools available which we would need to choose, learn, install, integrate, and maintain.
[Continuous integration, continuous deployment and continuous delivery](https://about.gitlab.com/2016/08/05/continuous-integration-delivery-and-deployment-with-gitlab/) are increasingly popular topics among modern development teams. Together they enable a team to build, test and deploy the code at any commit. The main benefit of these approaches is the ability to release more quality code more frequently through the means of automated pipelines. The tough part is building such pipelines. There is a myriad of tools available which we would need to choose, learn, install, integrate, and maintain.
Recently, I literally fell in love with [GitLab](https://gitlab.com/)! It offers a fully featured ecosystem of tools which enable us to create an automated pipeline in minutes! From source control to issue tracking and CI, we find everything under one roof, fully integrated and ready to use.
......@@ -86,9 +86,9 @@ git commit -m "Creates actuator-example application"
git push origin master
```
## Creating a Continuous Delivery pipeline with GitLab CI
## Creating a continuous delivery pipeline with GitLab CI
While our code is now safe on GitLab, we still need to automate its integration and deployment. We need to verify each commit with an automated build and set of tests in order to discover issues as early as possible and, if the build is successful, deploy to a target environment. A few years ago, our only option was to install, configure and maintain a CI Server like [Jenkins](https://jenkins.io/) and possibly automate our deployment with a set of bash scripts. While the number of options has grown significantly, whether hosted or on the cloud, we still need to find a way to integrate our source control system with the CI Server of our choice.
While our code is now safe on GitLab, we still need to automate its integration and deployment. We need to verify each commit with an automated build and set of tests in order to discover issues as early as possible and, if the build is successful, deploy to a target environment. A few years ago, our only option was to install, configure and maintain a CI Server like [Jenkins](https://jenkins.io/) and possibly automate our deployment with a set of bash scripts. While the number of options has grown significantly, whether hosted or on the cloud, we still need to find a way to integrate our source control system with the CI Server of our choice.
Not anymore though! GitLab has fully integrated CI and CD Pipelines in its offering, allowing us to [build, test and deploy](https://about.gitlab.com/2016/10/25/gitlab-workflow-an-overview/#build-test-and-deploy) our code with ease.
......@@ -117,7 +117,7 @@ git commit -m "Adds Dockerfile"
git push origin master
```
### Define the Kubernetes Deployment
### Define the Kubernetes deployment
Let's create a file named `deployment.yml` in the root directory of our project.
......@@ -201,7 +201,7 @@ k8s-deploy:
- gcloud container clusters get-credentials actuator-sample
- kubectl delete secret registry.gitlab.com
- kubectl create secret docker-registry registry.gitlab.com --docker-server=https://registry.gitlab.com --docker-username=marcolenzo --docker-password=$REGISTRY_PASSWD --docker-email=lenzo.marco@gmail.com
- kubectl apply -f deployment.yml
- kubectl apply -f deployment.yml
```
Let's break the file in pieces to understand what is going on.
......@@ -224,7 +224,7 @@ variables:
SPRING_PROFILES_ACTIVE: gitlab-ci
```
This is the definition of [`variables`](https://docs.gitlab.com/ce/ci/yaml/#variables) to be set on our build environment. The `DOCKER_DRIVER` signals the Docker Engine which storage driver to use. We use `overlay` for [performance reasons](https://docs.gitlab.com/ce/ci/docker/using_docker_build.html#using-the-overlayfs-driver). The `SPRING_PROFILES_ACTIVE` is very useful when dealing with Spring Boot applications. It activates [Spring Profiles](http://docs.spring.io/autorepo/docs/spring-boot/current/reference/html/boot-features-profiles.html), which provide a way to segregate parts of our application configuration and make it available only in certain environments. For instance, we can define different database URIs per environment, e.g. `localhost` when running on the developer machine and `mongo` when running within GitLab CI.
This is the definition of [`variables`](https://docs.gitlab.com/ce/ci/yaml/#variables) to be set on our build environment. The `DOCKER_DRIVER` signals the Docker Engine which storage driver to use. We use `overlay` for [performance reasons](https://docs.gitlab.com/ce/ci/docker/using_docker_build.html#using-the-overlayfs-driver). The `SPRING_PROFILES_ACTIVE` is very useful when dealing with Spring Boot applications. It activates [Spring Profiles](http://docs.spring.io/autorepo/docs/spring-boot/current/reference/html/boot-features-profiles.html), which provide a way to segregate parts of our application configuration and make it available only in certain environments. For instance, we can define different database URIs per environment, e.g. `localhost` when running on the developer machine and `mongo` when running within GitLab CI.
#### Stages
......@@ -251,7 +251,7 @@ maven-build:
This is a job definition. Jobs can have any name except keywords. Have a look at the `.gitlab-ci.yml` [documentation](https://docs.gitlab.com/ce/ci/yaml/) for the complete list of keywords.
The scope of this job is to perform a [Maven](https://maven.apache.org/index.html) build. For this reason, we define the `maven:3-jdk-8` as the Docker image on which this job should execute. This image comes with Maven 3 and the Java JDK 8 pre-installed for us.
The scope of this job is to perform a [Maven](https://maven.apache.org/index.html) build. For this reason, we define the `maven:3-jdk-8` as the Docker image on which this job should execute. This image comes with Maven 3 and the Java JDK 8 pre-installed for us.
We then specify `build` as the `stage` of this job. Jobs associated with the same stage run concurrently. This is extremely useful if you need to cross-compile your application. For instance, if we wanted to compile and test our application also on Java JDK 7, we could simply create another job with a different name and use the image `maven:3-jdk-7`.
......@@ -287,9 +287,9 @@ docker-build:
The `docker-build` job packages the application into a Docker container. We define `package` as the build `stage` since we need the `maven-build` job to produce the executable JAR beforehand.
The scripts are a typical sequence of `docker` commands used to build an image, log in to a private registry and push the image to it. We will be pushing images to the [GitLab Container Registry](https://about.gitlab.com/2016/05/23/gitlab-container-registry/).
The scripts are a typical sequence of `docker` commands used to build an image, log in to a private registry and push the image to it. We will be pushing images to the [GitLab Container Registry](https://about.gitlab.com/2016/05/23/gitlab-container-registry/).
The [`$CI_BUILD_TOKEN`](https://docs.gitlab.com/ce/user/project/new_ci_build_permissions_model.html#container-registry) is a pre-defined variable which is injected by GitLab CI into our build environment automatically. It is used to log in to the GitLab Container Registry.
The [`$CI_BUILD_TOKEN`](https://docs.gitlab.com/ce/user/project/new_ci_build_permissions_model.html#container-registry) is a pre-defined variable which is injected by GitLab CI into our build environment automatically. It is used to log in to the GitLab Container Registry.
For a complete list of pre-defined variables, have a look at the [variables documentation](https://docs.gitlab.com/ce/ci/variables/README.html#variables).
{: .alert .alert-info}
......@@ -314,12 +314,12 @@ k8s-deploy:
- echo "$GOOGLE_KEY" > key.json # Google Cloud service account key
- gcloud auth activate-service-account --key-file key.json
- gcloud config set compute/zone europe-west1-c
- gcloud config set project actuator-sample
- gcloud config set project actuator-sample
- gcloud config set container/use_client_certificate True
- gcloud container clusters get-credentials actuator-example
- kubectl delete secret registry.gitlab.com
- kubectl create secret docker-registry registry.gitlab.com --docker-server=https://registry.gitlab.com --docker-username=marcolenzo --docker-password=$REGISTRY_PASSWD --docker-email=lenzo.marco@gmail.com
- kubectl apply -f deployment.yml
- kubectl apply -f deployment.yml
```
We use the `google/cloud-sdk` image for this process since it comes preloaded with `gcloud` and all components and dependencies of the Google Cloud SDK including alpha and beta components. We obviously chose `deploy` as the `stage` since we want our application to be packaged beforehand and its container pushed to the GitLab Container Registry. Then we execute a set of scripts.
......
---
title: "Customer Story: A creative agency's GitLab wishlist"
title: "Customer story: A creative agency's GitLab wishlist"
author: Emily von Hoffmann
author_twitter: emvonhoffmann
categories: customer stories
......
---
title: "How to Keep Remote (Volunteer) Teams Engaged"
title: "How to keep remote (volunteer) teams engaged"
author: Emily von Hoffmann
author_twitter: emvonhoffmann
categories: customer stories
......@@ -64,7 +64,7 @@ We also have a second type of meeting, which is an open meeting focused on a cer
**James:** How else do people reach out to work together?
{: .alert .alert-info}
**Eliran:** We use Slack for communication, and I'm not sure how that would work in an environment like yours, without volunteers dedicating a certain amount of time every day. But we have channels for everything, and the whole team is distributed across channels. We have #general, which is the channel Emily used to ask "Hey is there anyone relevant who'd like to help James and talk about remote work at his organization?" We also have a #questions channel, where anyone can ask anything from the most sophisticated to the stupidest. They just throw their question to the channel and people try to help them or steer them in the right direction for who to talk to. Another channel that's really important is the #thanks channel, and I feel that's an important part to offer gratitude to someone for helping you, and also receive that when you've helped someone. Because of the remote environment it's very powerful. Because GitLab's culture is built on asynchronous work – people in different time zones – you're not on Slack all the time because others will pick up your question whenever they become available.
**Eliran:** We use Slack for communication, and I'm not sure how that would work in an environment like yours, without volunteers dedicating a certain amount of time every day. But we have channels for everything, and the whole team is distributed across channels. We have #general, which is the channel Emily used to ask "Hey is there anyone relevant who'd like to help James and talk about remote work at his organization?" We also have a #questions channel, where anyone can ask anything from the most sophisticated to the stupidest. They just throw their question to the channel and people try to help them or steer them in the right direction for who to talk to. Another channel that's really important is the #thanks channel, and I feel that's an important part to offer gratitude to someone for helping you, and also receive that when you've helped someone. Because of the remote environment it's very powerful. Because GitLab's culture is built on asynchronous work – people in different time zones – you're not on Slack all the time because others will pick up your question whenever they become available.
One other thing that's working well is centralizing a process for working asynchronously. So, we try to make all the work and communication and discussion on GitLab by using issues. Someone will create an issue with a particular task or mission, and then the whole communication is available there. So people have access to information or decisions or a process on a specific area. Even if you're not involved, you can comment and say, "Hey I'd like to suggest a, b, c." So by virtue of being in different time zones, we were forced to use asynchronous methods of work, and issues work very well for that. Having the discussion tools integrated into that, and using it to keep everything in one work space dedicated to a specific topic, is great for remote teams. If you can't always set a time for everyone to sit down together, using issues is crucial to making work happen.
......
---
title: "GitLab 8.15 Released with Auto Deploy and Web Terminal"
title: "GitLab 8.15 released with Auto Deploy and Web Terminal"
categories: release
author: Job van der Voort
author_twitter: Jobvo
......
......@@ -16,21 +16,21 @@ More and more organizations are conducting interviews and meetings using video p
Read on for our tips on how to avoid video chat nerves!
## Stage Your Interview Spot
## Stage your interview spot
It’s nice to be in a neutral environment that is a quiet and comfortable for you. That way neither you nor the interviewer gets too distracted by your environment. We encourage you to display your [quirkiness](/handbook/values) and personality, but for the interview it's best to avoid chaos. For example, we wouldn't suggest taking your interview call in a loud crowded cafe, in a car, or from your bed! These examples may sound extreme, but we have seen it all.
## Practice Your Positioning
## Practice your positioning
During the interview, you can’t exactly make eye contact with the interviewer, so the interviewer should clearly be able to see your face. Before the interview, check your front-facing camera or webcam to make sure you are well
lit and can be seen!
## Test Your Tech
## Test your tech
Nothing is worse than realizing moments before your call that you don’t have strong enough wifi, don’t know how to use the video platform, or can’t get your mic to work! Test your equipment and the video platform before
your interview, and avoid technical snags the day of! It’s also worthwhile to make sure your computers are fully charged or plugged in, and you have earphones with a good mic (this helps minimize echo). We suggest using a webcam or your built-in camera on your laptop for the interview instead of using a phone or tablet.
## Do Your Research
## Do your research
At GitLab, we love when candidates have reviewed our [handbook](/handbook) and know our [values](/handbook/values). Many of our [interview questions](/handbook/hiring/#interview-questions) can even be found in our [hiring process](/handbook/hiring), making preparation simple. Making a great first impression is not reserved for on-site interviews.
......
---
title: "Set Expectations, Manage Better"
title: "Set expectations, manage better"
author: Job van der Voort
author_twitter: Jobvo
image_title: '/images/blogimages/set-expectations-manage-better.jpg'
......
......@@ -15,7 +15,7 @@ A little while ago, we presented a first draft of our vision for monitoring with
<iframe src="https://www.youtube.com/embed/NFPGtbQfL1A" frameborder="0" allowfullscreen="true"> </iframe>
</figure>
## GitLab Monitoring Vision 0.1
## GitLab monitoring vision 0.1
Thanks everyone for joining. Just to level set: This call is to go over a first draft of our vision for monitoring within GitLab. A version 0.1 of the vision, if you will. I’m presenting it so Sid and others can ask questions and critique it, and to share more broadly. If you’re looking for a polished presentation about a well-defined product, this is the wrong place. :)
......@@ -24,7 +24,7 @@ I’ll start by talking about a potential minimum viable product (MVP), and then
And if you want to play along at home, here’s a link to your personalized [buzzword bingo card](http://bit.ly/2hP4xTn) for the presentation.
## Minimum Viable Product (MVP)
### Use Prometheus to Monitor GitLab Installation
### Use Prometheus to monitor GitLab installation
So the first step is to add [Prometheus](https://prometheus.io/) to monitor GitLab installations themselves. I won’t go into details here; and I believe [Pablo will be giving a talk about how we’re using it](https://gitlab.com/gitlab-com/marketing/issues/594). But in short, Prometheus is an open source monitoring solution. We’ve been using it internally here, and we’re going to bundle it up with GitLab CE so you can use it to monitor your own instances of GitLab.
......@@ -45,7 +45,7 @@ Here’s a couple screenshots I cribbed from some of those issues. Again, I’m
## MVP+3
### Web Application Monitoring
### Web application monitoring
I kind of tongue-in-cheek called this MVP+3, but after some number of iterations, the next **major** step is to [use Prometheus to monitor end-user applications](https://gitlab.com/gitlab-org/gitlab-ce/issues/23841). Ideally, providing a [New Relic](https://newrelic.com/)-like experience. Maybe it’s more accurate to say [Heroku-like monitoring](https://devcenter.heroku.com/articles/metrics) experience. New Relic does TONS of things we won’t touch for a long time, if ever. I believe there’s always a place for dedicated monitoring solutions that go deep. Our unique value won’t be in the deepness of the monitoring, it’ll be in the integration of monitoring into the rest of the experience. That may not be apparent in the initial release, but will show up later.
......@@ -60,7 +60,7 @@ We’ll start by measuring throughput, latency (or response time), and error rat
But measuring resources such as CPU, memory, and I/O might be easier for an MVP, so I’m keeping that open. Kubernetes may make some parts of that easier, but others harder. I don’t believe we should do all of this for an MVP, so my preference would be the web response side of things. The thinking goes: if one of the resources are constrained, say memory is entering swap too much, then that will show up as latency in the system. So I’d rather observe the material impact to the user directly. Unfortunately that means you don’t see anything until it’s already an impact. And knowing that latency is bad or error rates are up doesn’t help you debug the situation. That’s where resource monitoring can be useful. But still, as a first step, I want to know how my users are impacted and THEN find a way to debug it, at which point I may very well fire up New Relic to do more powerful analysis.
### Monitoring Alert on Merge Request
### Monitoring alert on merge request
So to show how we’re thinking of integrating monitoring, here’s a merge request, that has already been merged and deployed to production. Because we’ve got monitoring, GitLab noticed that memory usage increased right after the deploy, so we get a message right on the merge request.
......@@ -69,7 +69,7 @@ So to show how we’re thinking of integrating monitoring, here’s a merge requ
Let’s zoom in a little more. We see the alert, plus some summary information, telling you the memory usage increased from 114MB to 127MB, and a little spark line so you can see it graphically. Maybe we’d add a percent increase to make it more concrete. Of course, we’d also send an email notification of this alert, to the author of the actual changes about the impact. That way, this isn’t just an ops problem, the person or people most likely to be be able to deal with it know as soon as possible.
Now let’s click through and see more details.
### Monitoring Dashboard
### Monitoring dashboard
So now we see something a little more traditional. This is an early mockup of how a monitoring dashboard could appear. Note even in this early stage, we’ve got lines showing when deploys happened, to help identify code changes that impacted performance. Maybe hovering over them would show a list of merge requests that were included in that deploy.
......@@ -78,7 +78,7 @@ So now we see something a little more traditional. This is an early mockup of ho
This dashboard would be available for all of your environments: production, staging, and review apps. Or maybe you’d only want to install it for production environments. I’m not sure yet.
The point is that monitoring is an essential part of environments, deployments, and MRs.
### Deployment History
### Deployment history
This is a screenshot cribbed from New Relic, but I could imagine some of this information show up on our deployment history pages.
......@@ -112,7 +112,7 @@ Lastly, we’ve got user-defined or business metrics like signups, conversions,
Now, I’ve pretty much just defined the entirety of several monitoring industries. Obviously we’re unlikely to be best-of-breed in all of these. At least not in the next release or two. So again, the focus really is how we can provide the biggest bang-for-buck, the 20% effort that delivers 80% of the value, and really leverage our unique value, and that’s in our deep integration; making everything easier to use because it’s already there, and more impactful because it’s integrated across the experience. Anyone can show a graph of performance, where you can see that deploy 123 of merge request XYZ caused a problem, but alerting right on the merge request itself, right after deploying it, and emailing the authors of the actual changes about their impact, well, that’s just the tip of the iceberg of how monitoring could permeate the developer experience.
### Deploy Monitoring
### Deploy monitoring
* Track status of deploy from start to finish
* Finer state detail (ready, preparing, waiting, deploying, finished, failed)
* Aware of rollout across multiple containers/servers
......@@ -129,7 +129,7 @@ So here’s an early mockup of how we could integrate this information into our
On staging, you see that the last deployment finished, but production has a deployment that is ongoing. Each square represents a container, managed by Kubernetes. Hovering over each one shows the server name and it’s current status. Clicking through might show more details about that container. Since this is the environment list, we also see our review apps, but we’ve hidden the deploy status by default since it’s less important for review apps. For any of these environments, you can click through to the monitoring dashboard I already showed.
### Deploy Monitoring++
### Deploy monitoring++
* Notify authors of MRs that their changes are now live or in staging
Now deploy monitoring is a rich area with lots of opportunities for growth. Here’s an image from someone else’s Deployboard that shows a Slack notification of a staging deploy, and @ mentioning everyone with code in that change.
......@@ -150,7 +150,7 @@ And then there’s blue/green deploy, which has a few definitions, but the one I
But again, these are standard deploy strategies that companies already use. Of course we want to support these best practices, but our challenge will be to integrate these closely into GitLab to deliver even more value from the integrated whole. Integrating deploy strategies with monitoring and our knowledge of the codebase, merge requests, and issues. Maybe an alert of a performance problem automatically generates a new issue labeled appropriately and assigned to the right person so it shows up in their todos.
### Feature Flags
### Feature flags
* Decouple deployment from delivery
* In-code flag to execute one path or another based on externally controllable settings
* Binary switch
......@@ -182,7 +182,7 @@ If done right, it’ll encourage a good rollout process, and make it trivially e
![User flags](/images/blogimages/monitoring/user-flags.png){: .shadow}
### Feature Monitoring
### Feature monitoring
Now to bring this back to monitoring, feature flags are another rollout mechanism, similar to some of the deployment strategies. So we should be able to [monitor these](https://gitlab.com/gitlab-org/gitlab-ce/issues/24254), showing some analysis/graphing on them.
Perhaps it’s a simple list of features and summary statistics about them indicating if they're performing as expected. Like:
* Feature X, rolled out to beta, decreased response time by 5%
......
---
title: "Why We Use Personas in Product Development"
title: "Why we use personas in product development"
author: "Sarah O’Donnell"
author_twitter: saraheod
author_gitlab: sarahod
......
---
title: "Tower Launches GitLab Integration on Windows"
title: "Tower launches GitLab integration on Windows"
author: Rebecca Dodd
author_twitter: Reberoodle
author_gitlab: rebecca
......@@ -16,13 +16,13 @@ This highly anticipated integration has been a popular request from Tower users
Here are some of the great ways this tight integration can help you:
## Tower Feature Highlights
## Tower feature highlights
### Services Manager
Manage your GitLab account right within Tower on Windows, and you can clone repositories with a single click – avoiding the hassle of usernames, passwords and authentication tokens.
### Productivity Boosters
### Productivity boosters
Work more quickly with productivity-enhancing features: automatic fetching from remote servers helps your team stay up to date and automatic stashing asks you at the right time if you want local changes on a Stash to avoid problems.
......@@ -32,11 +32,11 @@ Roll back to previous versions, discard local changes, revert to an old revision
![Tower Conflict Wizard](/images/blogimages/conflict-wizard@2x.png){: .shadow}
### Beginner Features
### Beginner features
With Tower you can see what you are doing and what changes are taking place without relying on the command line. Take advantage of learning resources including a video series, e-book and extensive documentation to help you learn Git.
### Features for Pros
### Features for pros
Discard single lines of code, cherry-pick individual commits, and enjoy extensive support for Submodules and git-flow.
......@@ -45,4 +45,4 @@ Ready to try out Tower with GitLab? Redeem this [coupon code](http://www.git-tow
_Tweet us [@GitLab](https://twitter.com/gitlab), check out our [job openings](https://about.gitlab.com/jobs/), or add your questions and suggestions to our [issue tracker](https://gitlab.com/gitlab-org/gitlab-ce/issues)!_
Image: "[Puzzle](https://www.flickr.com/photos/sterlic/4458413554)" by [Scott Akerman](https://www.flickr.com/photos/sterlic/) is licensed under [CC BY 2.0](https://creativecommons.org/licenses/by/2.0/)
{: .note}
\ No newline at end of file
{: .note}
---
title: "GitLab 8.16 Released with auto deploy on Google Container Engine and Prometheus monitoring as part of GitLab"
title: "GitLab 8.16 released with auto deploy on Google Container Engine and Prometheus monitoring as part of GitLab"
categories: release
author: Job van der Voort
author_twitter: Jobvo
......
---
title: "Video Tutorial: Idea to Production on Google Container Engine (GKE)"
title: "Video tutorial: Idea to Production on Google Container Engine (GKE)"
categories: tutorial
author: Sean Packham
author_twitter: SeanPackham
......
---
title: "Designing for the Modern Developer"
title: "Designing for the modern developer"
author: Emily von Hoffmann
author_twitter: emvonhoffmann
author_gitlab: evhoffmann
......@@ -8,40 +8,40 @@ image_title: '/images/blogimages/designing-for-the-modern-developer.jpg'
description: "Recap and recording from our recent webcast featuring the GitLab user experience (UX) team"
---
We're proud of how each team within the company delivers to make us better for every monthly release. Because GitLab spans the entire software development lifecycle, our UX team routinely tackles a series of unique creative challenges, which they discussed in depth in our recent webcast, "Designing for the Modern Developer."
We're proud of how each team within the company delivers to make us better for every monthly release. Because GitLab spans the entire software development lifecycle, our UX team routinely tackles a series of unique creative challenges, which they discussed in depth in our recent webcast, "Designing for the Modern Developer."
UX Lead Allison Whilden and UX Researcher Sarah O'Donnell chat about how the team designs the interface, responds to feedback, and helps fit new features into our understanding of the needs of all users.
UX Lead Allison Whilden and UX Researcher Sarah O'Donnell chat about how the team designs the interface, responds to feedback, and helps fit new features into our understanding of the needs of all users.
Watch the recording and get the highlights below.
Watch the recording and get the highlights below.
<figure class="video_container">
<iframe src="https://www.youtube.com/embed/nnL48m0m4qo" frameborder="0" allowfullscreen="true"> </iframe>
</figure>
## Highlights
## Highlights
### How We Make Design Decisions
### How we make design decisions
> At every stage, we carefully think through why decisions are made, and for whom. We have a number of methods that help us do this: research, testing, surveys, working with internal devs, and carrying on a constant conversation with our community.
> At every stage, we carefully think through why decisions are made, and for whom. We have a number of methods that help us do this: research, testing, surveys, working with internal devs, and carrying on a constant conversation with our community.
### Users of Our Own Design
### Users of our own design
> We’re pretty unique in that every day, we use our own product. This gives us an intimate understanding of how the software is used. It empowers us as users with opinions, and also forces us to be extra thoughtful about removing bias from our evaluation of the UX. We take seriously that we need to represent all opinions, not just our own. UX is about calculated decisions, not anyone’s idea about what they like best. We naturally adopt a sort of split brain when using the software and observing user behavior--we empathize both as users and technical experts.
> We’re pretty unique in that every day, we use our own product. This gives us an intimate understanding of how the software is used. It empowers us as users with opinions, and also forces us to be extra thoughtful about removing bias from our evaluation of the UX. We take seriously that we need to represent all opinions, not just our own. UX is about calculated decisions, not anyone’s idea about what they like best. We naturally adopt a sort of split brain when using the software and observing user behavior--we empathize both as users and technical experts.
### How We Work With Engineering & Product
### How we work with Engineering and Product
> Being a remote startup, we have a rather unique challenge of building a shared vision and perspective for UX while we are scattered across the world, and across features of the product. We’re working on this by documenting everything in our [UX Guide](https://docs.gitlab.com/ce/development/ux_guide/index.html), which you’re free to read through. More and more of the industry is becoming remote, so we’re excited to be experimenting with ways to stay connected. We believe that what we learn will be increasingly valuable to other companies. We navigate our relationship with the product team by understanding that they are both users & builders, too.
### We're Sensitive to Different Needs & Workstyles
### We're sensitive to different needs and work styles
> We’re opinionated - we have a GitLab workflow, which we use at GitLab, the company, but we understand that not everyone works the way we do. Some of our company values, like extreme transparency, need to be made “optional” for users in other companies, for example when we think about how permissions work.
We also build things that we ourselves don’t currently need.
### How We Balance Feedback
### How we balance feedback
> In order to keep up with releases and deliver minimum viable change, we need to amplify some voices. When we have to prioritize, we address issues from our Enterprise customers first, then from our outside community, and then from developers on our team.
> In order to keep up with releases and deliver minimum viable change, we need to amplify some voices. When we have to prioritize, we address issues from our Enterprise customers first, then from our outside community, and then from developers on our team.
### Our UX Research Interests
### Our UX research interests
> We want to build an understanding of who our users are and how they work. While we get a lot of great feedback from the community that is really helpful, we aren't always sure we are capturing the full range of our target users. We're developing personas that will allow us to relate to different types of users and subsequently predict their behavior. This is essential for our key challenge of creating a unified experience for teams big and small, so they can stay focused on their own goals.
>
......@@ -52,5 +52,3 @@ You can learn more about this in our recent [blog post](https://about.gitlab.com
Cover image: "[sampa](https://www.flickr.com/photos/hernaniarruda/16024464453)" by [Hernani Arruda Monteiro da Silva](https://www.flickr.com/photos/hernaniarruda/) is licensed under [CC BY 2.0](https://creativecommons.org/licenses/by/2.0/legalcode).
{:.note}
......@@ -26,7 +26,7 @@ with pens like this, [created][pen] by [Jase Smith]:
When I heard that they had switched to GitLab, I was thrilled! Yaaay!
&nbsp;<i class="fa fa-codepen" aria-hidden="true"></i>
&nbsp;**CodePen, welcome to GitLab!**
&nbsp;**CodePen, welcome to GitLab!**
&nbsp;<i class="fa fa-gitlab" aria-hidden="true"></i>
They're very cool folks, and their [team][team] is making such an
......@@ -35,7 +35,7 @@ awesome product! They're also [remote only](https://www.remoteonly.org/), like u
Listen to their podcast, which details why they moved and how it
went. If you'd rather read, we've included some of the highlights below.
## Listen Now
## Listen now
<figure>
<audio class="shadow" preload="none" style="width: 100%;" controls="controls">
......@@ -55,7 +55,7 @@ Source: [Codepen Radio - 114 - GitLab](https://blog.codepen.io/2017/01/24/114-gi
### <i class="fa fa-cog fa-fw" aria-hidden="true"></i> Control
{: .panel-heading}
<div class="panel-body">
5:18. The first thing they talked about is "control".
5:18. The first thing they talked about is "control".
7:45. They can't rely on a third-party service to deploy
their code. Whenever there's downtime, there's nothing they can do about it. With a self-hosted GitLab instance,
......@@ -68,7 +68,7 @@ they have the ability to exercise control over their server and everything else.
{: .panel-heading}
<div class="panel-body">
10:00. Because it's self-hosted, they feel much more protected from hacker attacks and system breaches.
They have their own private network space in which they run GitLab.
They have their own private network space in which they run GitLab.
> 12.35. _We have control, we have code in our own network, we have higher security._
</div>
......@@ -99,7 +99,7 @@ deploy their code. [GitLab CI][ci] does this job, and it's built-in in GitLab.
They also enjoy not having to deploy from the command line, as it was impossible to track.
17:15. They love our [Pipelines][pipes], where the entire team can see what's going on and who's doing what. The steps are visible.
17:15. They love our [Pipelines][pipes], where the entire team can see what's going on and who's doing what. The steps are visible.
> 17:27. _It's very clear, in GitLab, whether a build on staging has actually been pushed to production. So, if I'm going to deploy something to production, I can very easily see who has moved that into master since the last production deploy._
......@@ -157,7 +157,7 @@ from the UI, which means pushing a button.
<div class="panel-body">
There's one thing they are missing: squash-merge. Good news for y'all: we have something like that [coming][squash] soon!
At 33:44 they also mention burndown charts, and there is [an issue][burndown] for that with a lot of traction.
At 33:44 they also mention burndown charts, and there is [an issue][burndown] for that with a lot of traction.
> 34:03. _My final feeling about GitLab is it's incredibly impressive work. Like, holy crap, this is really good software! High five team!_ 🙌
......
---
title: "Getting Started with Git LFS"
title: "Getting started with Git LFS"
author: Tobias Günther
author_twitter: gntr
author_gitlab: tobidobi
......@@ -22,7 +22,7 @@ The general benefits of version control still apply and should be reaped in all
Luckily, there's a Git extension that makes working with large files a lot more efficient: say hello to "[Large File Storage](https://git-lfs.github.com/)" (or simply "LFS" if you prefer nicknames).
## Without LFS: Bloated Repositories
## Without LFS: Bloated repositories
Before we look at how exactly LFS works its wonders, we'll take a closer look at the actual problem.
Let's consider a simple website project as an example:
......@@ -42,7 +42,7 @@ Very quickly, the repository will weigh tons of megabytes and soon gigabytes - w
Although I only talked about "design" files, this is really a problem with all "large" files:
movies, audio recordings, datasets, etc.
## With LFS: Efficient Large File Handling
## With LFS: Efficient large file handling
Of course, LFS cannot simply "magic away" all that large data: it accrues with every change and has to be saved.
However, it shifts that burden to the remote server - allowing the _local_ repository to stay relatively lean!
......@@ -57,18 +57,18 @@ Thereby, you end up with only the files you really want - not a whole bunch of s
## Installing LFS
LFS is not (yet) part of the core Git binary, but it's available as an extension.
LFS is not (yet) part of the core Git binary, but it's available as an extension.
This means that, before we can work with LFS, we need to make sure it's installed.
#### Server
Not all code hosting services support LFS already. As a GitLab user, however, there's not much to worry about:
Not all code hosting services support LFS already. As a GitLab user, however, there's not much to worry about:
if you're using GitLab.com or a halfway recent version of GitLab CE or EE, [support for LFS is already baked in](https://docs.gitlab.com/ce/workflow/lfs/manage_large_binaries_with_git_lfs.html)!
Your administrator only need to [enable the LFS option](https://docs.gitlab.com/ce/workflow/lfs/lfs_administration.html).
#### Local Machine
#### Local machine
Your local Git installation also needs to support LFS.
Your local Git installation also needs to support LFS.
If you're using [Tower](https://www.git-tower.com/?utm_source=gitlab-blog&utm_campaign=GitLab%20LFS&utm_medium=guest-post), a Git desktop client, you don't have to install anything: Tower supports the Git Large File System out of the box.
If you're using Git on the command line, there are different installation options available to you:
......@@ -79,14 +79,14 @@ If you're using Git on the command line, there are different installation option
- Windows: You can use the [Chocolatey](https://chocolatey.org/) package manager via "choco install git-lfs".
After your package manager has finished its work, you need to complete the installation with the "lfs install" command:
```
git lfs install
```
## Tracking Files with LFS
## Tracking files with LFS
Without further instructions, LFS won't take care of your large file problems.
Without further instructions, LFS won't take care of your large file problems.
We'll have to tell LFS explicitly which files it should handle!
So let's return to our "big Photoshop file" example. We can instruct LFS to take care of the "design.psd" file using the "lfs track" command:
......@@ -98,11 +98,11 @@ git lfs track "design-resources/design.psd"
At first glance, the command didn't seem to have much effect. However, you'll notice that a new file in the project's root folder has been created (or changed, if it already existed): `.gitattributes` collects all file patterns that we choose to track via LFS. Let's take a look at its contents:
```
cat .gitattributes
cat .gitattributes
design-resources/design.psd filter=lfs diff=lfs merge=lfs -text
```
Perfect! From now on, LFS will handle this file. We can now go ahead and add it to the repository in the way we're used to.
Perfect! From now on, LFS will handle this file. We can now go ahead and add it to the repository in the way we're used to.
Notice that any changes to `.gitattributes` also have to be committed to the repository, just like other modifications:
```
......@@ -111,9 +111,9 @@ git add design-resources/design.psd
git commit -m "Add design file"
```
## Tracking File Patterns
## Tracking file patterns
Adding a specific, single file like this is all well and good... but what if you want to track, for example, _every_ `.indd` file in our project?
Adding a specific, single file like this is all well and good... but what if you want to track, for example, _every_ `.indd` file in our project?
Please relax: you don't have to add each file manually! LFS allows you to define file patterns, much like when ignoring files.
The following command, for example, will instruct LFS to track all _InDesign_ files - existing ones and future ones:
......@@ -127,19 +127,19 @@ You could also tell LFS to track the contents of a whole directory:
git lfs track "design-assets/*"
```
## Getting an Overview of Tracked Files
## Getting an overview of tracked files
At some point, you might want to know which files exactly are tracked by LFS at the moment.
You could simply take a look at the `.gitattributes` file. However, these are not _actual_ files, but only rules and therefore highly "theoretical": individual files might have slipped through, e.g. due to typos or overly restrictive rules.
At some point, you might want to know which files exactly are tracked by LFS at the moment.
You could simply take a look at the `.gitattributes` file. However, these are not _actual_ files, but only rules and therefore highly "theoretical": individual files might have slipped through, e.g. due to typos or overly restrictive rules.
To see a list of the _actual_ files that you're currently tracking, simply use the `git lfs ls-files` command:
```
git lfs ls-files
194dcdb603 * design-resources/design.psd
```
## Track as Early as Possible
## Track as early as possible
Remember that LFS does _not_ change the laws of nature: things that were committed to the repository are there to stay.
It's very hard (and dangerous) to change a project's commit history.
......@@ -153,8 +153,8 @@ The ideal moment to configure which file patterns you want to track is right whe
## Using LFS in a GUI
Although LFS is not difficult to use, there are still commands to remember and things to mess up.
If you want to be more productive with Git (and LFS), have a look at [Tower](https://www.git-tower.com/?utm_source=gitlab-blog&utm_campaign=GitLab%20LFS&utm_medium=guest-post), a Git desktop client for Mac and Windows.
Although LFS is not difficult to use, there are still commands to remember and things to mess up.
If you want to be more productive with Git (and LFS), have a look at [Tower](https://www.git-tower.com/?utm_source=gitlab-blog&utm_campaign=GitLab%20LFS&utm_medium=guest-post), a Git desktop client for Mac and Windows.
Since Tower comes with built-in support for Git LFS, there is nothing to install. The app has been around for several years and is trusted by over 80,000 users all over the world.
![Using Tower to be more productive with Git and Git LFS](/images/blogimages/getting-started-with-git-lfs-tutorial/tower-lfs.gif)
......@@ -163,18 +163,18 @@ Additionally, Tower provides a direct [integration with GitLab](https://about.gi
## Working with Git
A great aspect of LFS is that you can maintain your normal Git workflow: staging, committing, pushing, pulling and everything else works just like before.
A great aspect of LFS is that you can maintain your normal Git workflow: staging, committing, pushing, pulling and everything else works just like before.
Apart from the commands we've discussed, there's nothing to watch out for.
LFS will provide the files you need, _when_ you need them.
In case you're looking for more information about LFS, have a look at this free [online book](https://www.git-tower.com/learn/git/ebook/en/desktop-gui/advanced-topics/git-lfs?utm_source=gitlab-blog&utm_campaign=GitLab%20LFS&utm_medium=guest-post).
In case you're looking for more information about LFS, have a look at this free [online book](https://www.git-tower.com/learn/git/ebook/en/desktop-gui/advanced-topics/git-lfs?utm_source=gitlab-blog&utm_campaign=GitLab%20LFS&utm_medium=guest-post).
For general insights about Git, take a look at the [Git Tips & Tricks](/2016/12/08/git-tips-and-tricks/) blog post and Tower's [video series](https://www.git-tower.com/learn/git/videos?utm_source=gitlab-blog&utm_campaign=GitLab%20LFS&utm_medium=guest-post).
## About Guest Author
This is a [guest post](/handbook/marketing/blog/#guest-posts)
This is a [guest post](/handbook/marketing/blog/#guest-posts)
written by [Tobias Günther](https://twitter.com/gntr), who is part of the team behind the [Tower Git client](https://www.git-tower.com/?utm_source=gitlab-blog&utm_campaign=GitLab%20LFS&utm_medium=guest-post).
Cover image: screenshot of [Git LFS](https://git-lfs.github.com/)
{:.note}
\ No newline at end of file
{:.note}
---
title: "Around the World in 6 Releases"
title: "Around the world in 6 releases"
author: Douwe Maan
author_twitter: DouweM
author_gitlab: DouweM
......@@ -28,7 +28,7 @@ On the other hand, we realize that one of the downsides of remote work is that,
One of the things we do to help our team members [connect and stay connected](/2016/12/05/how-we-stay-connected-as-a-remote-company/) uses that advantage to combat the downside: we encourage everyone to [travel to visit and work with other team members](/handbook/spending-company-money/#travel-to-visit-team-members), wherever they may be, and will cover any travel costs to get there.
(It's in the handbook, so it's true!)
## The Trip
## The trip
In early 2016, I (Douwe) was trying to figure out how to spend the year and realized that my [remote-only](http://www.remoteonly.org/) job at GitLab gave me a unique opportunity to combine two of my favorite things: travel, and work. I decided to travel for six months, visiting [GitLab colleagues](/team/) around the world to get to know them better, work with them, and see some of the beautiful places our planet has to offer in the process. I dubbed it "Around the World in 6 Releases."
......
---
title: "GitLab.com Database Incident"
title: "GitLab.com database incident"
author: GitLab
author_twitter: gitlab
categories:
......@@ -21,7 +21,7 @@ As of time of writing, we’re restoring data from a six-hour-old backup of our
Read below for a brief summary of the events. You’re also welcome to view [our active postmortem doc](https://docs.google.com/document/d/1GCK53YDcBWQveod9kfzW-VCxIABGiryG7_z_6jHdVik/pub).
## First Incident
## First incident
At 2017/01/31 6pm UTC, we detected that spammers were hammering the database by creating snippets, making it unstable. We then started troubleshooting to understand what the problem was and how to fight it.
......@@ -42,7 +42,7 @@ At 2017/01/31 9pm UTC, this escalated, causing a lockup on writes on the databas
- We removed a user for using a repository as some form of CDN, resulting in 47 000 IPs signing in using the same account (causing high DB load)
- We removed users for spamming (by creating snippets)
## Second Incident
## Second incident
At 2017/01/31 10pm UTC, we got paged because DB Replication lagged too far behind, effectively stopping. This happened because there was a spike in writes that were not processed ontime by the secondary database.
......@@ -62,7 +62,7 @@ At 2017/01/31 10pm UTC, we got paged because DB Replication lagged too far behin
- `db2.cluster` still refuses to replicate, though it no longer complains about connections; instead it just hangs there not doing anything
- At this point frustration begins to kick in. Earlier this night _team-member-1_ explicitly mentioned he was going to sign off as it was getting late (23:00 or so local time), but didn’t due to the replication problems popping up all of a sudden.
## Third Incident
## Third incident
At 2017/01/31 11pm-ish UTC, _team-member-1_ thinks that perhaps `pg_basebackup` is refusing to work due to the PostgreSQL data directory being present (despite being empty), decides to remove the directory. After a second or two he notices he ran it on `db1.cluster.gitlab.com`, instead of `db2.cluster.gitlab.com`.
......@@ -77,7 +77,7 @@ We had to bring GitLab.com down and shared this information on Twitter:
</div>
## Problems Encountered
## Problems encountered
- LVM snapshots are by default only taken once every 24 hours. _Team-member-1_ happened to run one manually about six hours prior to the outage because he was working in load balancing for the database.
- Regular backups seem to also only be taken once per 24 hours, though _team-member-1_ has not yet been able to figure out where they are stored. According to _team-member-2_ these don’t appear to be working, producing files only a few bytes in size.
......