В этой статье я расскажу про основные принципы работы с распределённой Version Control Systems – git, которая на сегодняшний день является наиболее популярной.
Почитать историческую справку и сравнение с другими VCS можно тут – https://ru.wikipedia.org/wiki/Git
Про то, как Git устроен внутри почитать можно тут
На сегодняшний день работа с Git является обязательной не только для DevOps, но и для любого ит-специалиста который занимается автоматизацией, управлением конфигурациями и т.д.
1. Структура данных
If you’re working with GitHub you definitely should consider Gists for smaller pieces of code, like scripts.
As soon as you start you might want to commit to Gists using SSH, and GUI provides such option:
Both Jenkins and GitHub are very popular, so it couldn’t be a problem integrating them. It still might be a bit confusing if you’re doing it for the first time. That’s why I decided to spend a few minutes to show you guys how it can be done.
Jenkins master can be accessed through the URL different from the one specified in Jenkins configuration.
Why might we need this? Well, you probably want your Jenkins server to be publicly accessible (this is required for GitHub integration, by the way) and since it’s public you typically want to use an encrypted HTTPS connection.
Well, you can install nginx proxy to achieve this, but in this case you’ll have to maintain SSL certs, which obviously sucks, especially if you can use AWS Certificate Manager with AWS ELB.
Another reason to use different URL is to save your time. When you use Windows slaves via JNLP there’re well-known issues with both nginx and load balancers.
And the last but not least reason is that “LAN” connection between Jenkins master and slaves is still more secure and faster, so it’s preferable in most cases.
So let’s start implementing Jenkins and GitHub integration within these conditions!
In this post we’ll consider rather common situation when you’ve got application with dedicated configuration file and at least two environments: dev and prod.
Application in dev env is using dev database and prod application is using prod database;
Database connection strings are stored in app.config file, so you have to have different app.config files in dev and prod Git branches.
The most common suggestion about managing this challenge is to use git attributes merging policy, so let’s see how to deal with it.
In this post I’ll show how Git repo can be completely transferred from BitBucket to Visual Studio Team Services.
However, this instruction will be relevant for Git repo transfer between any origins, such as GitHub, Stash, GitLab, etc.
Before migration starts, it’s important to commit and push all changes from local repositories to the current origin (which happens to be BitBucket in our example).
If you work with a small team you might not need such powerful tool as Jira, but you still need to be able to use tasks, bugs and proposals.
In this case BitBucket issues are exactly what you need.
BitBucket issues support well-formatted descriptions, attachments, assignees, kinds and priorities – almost all that your small team might need:
Fork gives us awesome power to suggest improvements to open-source projects, but it also can be used in enterprise scenarios.
In this example I’ll review the most common scenario when a user will make some improvements for open-source project.
If you’re working as a team member on some feature you probably will work in dedicated branch.
Once your work is done you want it to be tested – merge code to qa branch:
Stash is not a very common but useful function, something like “Pause” button for your local changes.
For example, you’re working on some stuff in dev branch and you need to get branch clean (as it was in the last commit).
Of course you can commit your stuff and switch to previous commit, but lots of commits might complicate team work.
This is where the Stash would be helpful – it will save uncommitted changes internally and I’ll be able to come back to them later with git stash pop command:
To restore file from one of the previous commits or tags do this:
Изменения, которые вносятся в Git чрезвычайно важны, а значит логи должны быть достаточно подробными и хранится надёжно.