Forem: Slava Vasenin

How to clean your git history

Slava Vasenin — Mon, 16 Mar 2020 12:31:04 +0000

Hi!
I want to share you a short instruction on how to remove wrong or mistaken commits from a remote repository when you don't want to make a revert.

Check changes and find what commits you want to remove.

$ git log --stat

Use the interactive rebase command.

$ git rebase -i HEAD~X

Put the number of commits instead of X which you want to remove. Better to add a bit more to view the previous ones also. So, you need to remove 1 commit add number 3.

You will see something like this:

pick a0b45b373 Dynamic field featured image url fixed
pick 8e8d27747 Update render condition for feedback popup component
pick 843770a32 Add dev.to version

# Rebase 680ac7c26..843770a32 onto 680ac7c26 (3 commands)
#
# Commands:
# p, pick <commit> = use commit
# r, reword <commit> = use commit, but edit the commit message
# e, edit <commit> = use commit, but stop for amending
# s, squash <commit> = use commit, but meld into previous commit
# f, fixup <commit> = like "squash", but discard this commit's log message
# x, exec <command> = run command (the rest of the line) using shell
# b, break = stop here (continue rebase later with 'git rebase --continue')
# d, drop <commit> = remove commit

I use Vim as default text editor for Git.

Replace the word pick with the word drop or d for those commits that you want to remove. I remove only one, but I also checked and see that previous commits not related to my changes.

pick a0b45b373 Dynamic field featured image url fixed
pick 8e8d27747 Update render condition for feedback popup component
d 843770a32 Add dev.to version

Save and exit from your editor.

Check git status.

$ git status
On branch master
Your branch is behind 'origin/master' by 1 commit, and can be fast-forwarded.
  (use "git pull" to update your local branch)

nothing to commit, working tree clean

In some cases, there can be merge conflicts after rebase. Follow instructions to solve them.

The next step is to push it to your remote repository. You need to force this push because the remote repository will think that your current branch is behind.

git push -f

Go and check your remote repository.

That it. Thanks and Good luck 🚀

Cover image by Diana Mounter

How to measure deployment frequency for WordPress plugin

Slava Vasenin — Tue, 03 Mar 2020 15:02:40 +0000

One year ago I read a very great book about DevOps science "Accelerate".

There was a chapter about measurements that can be used to answer the question: Does your company has High-performance team in the development?

These measurements:

Deployment Frequency
Lead Time for changes
MTTR
Change Failure rate

One of the most interesting points is Deployment Frequency and we had a long discussion about this in my team about that. The book says that the high-performance team should deliver on-demand, multiple deploys per day.

The problem is that if we will publish one plugin every day multiple times in "WordPress.org" people won't like it because there are no automatic updates for Wordpress plugins in the admin dashboard.

So, Publishing so frequently isn't an option, but the concept to have a deliverable product as often as the possible sound really useful.

We use a trunk-based development branching model. What does it mean?

A source-control branching model, where developers collaborate on code in a single branch called ‘trunk’(master), resist any pressure to create other long-lived development branches by employing documented techniques. They, therefore, avoid merge hell, do not break the build, and live happily ever after.

There is a master branch were we merge all pull requests. Is it safe? From point of continues integrations, we run tests pipeline for every commit and every merge. Sound safe! How true is it? Not sure. No one during the merge of the pull request thinks it can be delivered to the customer at once.

The only thing left is to update the release brunch as frequently as possible. Here is our scenario:

Developer crates pull request. Before all CI pipeline's tests have been successfully completed.
A reviewer checks code and confirms this pull request as valid.
A reviewer merges pull request.
Release engineer checks during the day the state of the master branch and if it has updates, decides are this code safe for the update in the current release branch.

So every update counts as deployment. Makes sense, isn't it?

Conclusion

If you have any suggestions or you want to share what kind of practices you use in your company, please welcome to write comments :)

Thanks and Good Luck 🚀

How to get WordPress plugin release in GitHub actions

Slava Vasenin — Mon, 10 Feb 2020 15:18:16 +0000

We started to use GitHub actions to build Visual Composer release candidates in GitHub. This action will prepare a proper zip archive file which we can use to update our plugin in Wordpress.org.

We decided that the release will be built on the new tag. The tag will be the version of the published release.

on:
  push:
    tags:
      - '*'

We already had the script which was able to create a valid zip archive of Visual Composer Website Builder for Wordpress.org. It looks like this.

$ node _infrastructure/vcwb-builder/builder plugin -b VERSION -p ./_infrastructure

Yeah, this script will set plugin version also -b VERSION. The question is how to get the version from GitHub tag. There is access to $GITHUB_REF where we can get tags. I decide to create variable get_version which can be used in other steps of the job.

- name: Get the version
  id: get_version
  run: echo ::set-output name=VERSION::${GITHUB_REF/refs\/tags\//}

Then we just need to use steps.version_version in the next step.

- name: Build project
  run: |
    yarn install
    node _infrastructure/vcwb-builder/builder plugin -b ${{ steps.get_version.outputs.VERSION }} -p ./_infrastructure

The next action is to create Github release itself.

- name: Create Release
  id: create_release
  uses: actions/create-release@v1.0.0
  env:
    GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
  with:
    tag_name: ${{ github.ref }}
    release_name: ${{ github.ref }}
    draft: false
    prerelease: false

After release creation needs to upload our zip archive. I use actions/upload-release-asset@v1.0.1 action for that.

- name: Upload Release Asset
  id: upload_release_asset
  uses: actions/upload-release-asset@v1.0.1
  env:
    GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
  with:
    upload_url: ${{ steps.create_release.outputs.upload_url }}
    asset_path: ./_infrastructure/visualcomposer.zip
    asset_name: visualcomposer.zip
    asset_content_type: application/zip

That's it. The full version of the configuration file you can check here.

Good luck ✌️