Forem: Benjamin Justice

One-Click Deployments for Small Projects

Benjamin Justice — Sun, 08 Nov 2020 16:00:00 +0000

When we think of DevOps and deployments, we usually think about big fancy automated deployment pipelines.

Although I love deployment pipelines, others have written great articles and tutorials.

If you are looking to expand our Travis CI build server from Getting Started with Build Servers, its super easy to implement with the Travis CI documentation at https://docs.travis-ci.com/user/deployment/.

Instead I want to show you how I deploy small projects with a one-click deployment script.

Before continuing, make sure you know the PowerShell basics from my Cross-Platform Command Line article.

Writing a Deployment Script

For this example, we will deploy a WordPress theme. It’s a common use-case and does not require you to know anything about WordPress.

As for all small projects, we will follow four simple steps to help us determine how we will deploy via script.

Step 1: What do we need?

A WordPress theme is a simple directory with php, css and javascript files.

If you want to see an example, have a look at the TwentySeventeen sample theme.

As a wordpress theme only consists of this directory, we do not have any builds to upload. We simply upload our entire theme directory.

For this example, we will call this folder my-custom-theme.

Step 2: Where do we need it?

Now that we have a wordpress theme, where must we deploy it to?

For this example, we will assume that we have two servers:

dev.justice.sh – a private server for testing new code
justice.sh – a public server hosting your website

WordPress themes are installed by uploading them into the wp-content/themes directory. If you wish to learn more on the wordpress folder structure, this article gives a great overview.

So let’s say our target path is /var/www/wordpress/wp-content/themes.

Step 3: How do we transfer it?

While there are many ways to upload our theme, SSH and FTP are the most popular ones.

Because setting up FTP via script is a little more work, I prefer using SSH.

If you are using Windows 10, you must enable the OpenSSH client first.

First of all, make sure that you can access your server via ssh.

I recommend using ssh keys instead of username/password. See this article using windows + powershell.

If you are on mac or Linux, you can simply use ssh-keygen and ssh-copy-id.

Step 4: Script it!

With the above information, we can now write our two scripts.

Be sure to replace USERNAME with your own username:

deploy-dev.sh

#!/bin/sh

# Copy the directory 'my-custom-theme' to our target server via ssh.
scp -r my-custom-theme USERNAME@dev.justice.sh:/var/www/wordpress/wp-content/themes

deploy-prod.sh

#!/bin/sh

# Copy the directory 'my-custom-theme' to our target server via ssh.
scp -r my-custom-theme USERNAME@justice.sh:/var/www/wordpress/wp-content/themes

Conclusion

With the above two scripts, you can simply run ./deploy-dev.ps1 or ./deploy-prod.ps1 to deploy to DEV or PROD servers.

I like to commit my deployment scripts in git, so I always have them together with my projects.

And so this part of the Getting Started with DevOps series comes to a close.

If you have any questions or feedback, you can reach me on Twitter or on the BrutalHack Discord Server.

The post One-Click Deployments for Small Projects appeared first on justice.sh.

One Easy Trick to Manage Your Software Release

Benjamin Justice — Mon, 12 Oct 2020 07:42:00 +0000

A software release can be daunting. Software engineers learn how to plan, code, build and test their software. However many aren’t taught about releasing and maintaining software.

In this article I want to share one of the simplest and most effective tools for planning your software release: The software release checklist.

I will not assume any prior knowledge for the last phases in our DevOps Lifecycle. If you have no clue about releasing software, this is for you.

What is a Software Release?

The DevOps Lifecycle defines 4 phases after you have finished developing your software version:

Release
Deploy
Operate
Monitor

As you can see, actually uploading and distributing the software is the next step, Deploy.

Before we get to that phase, we should plan, schedule and communicate our release. This may sound like a lot of management and, for big corporations, this is also the case. However if you are in a small business or startup, this can be solved with one of the easiest tools available.

The Software Release Checklist

A good software release is all about managing the process.

And the simplest way to manage a process is with a checklist.

I will share my release checklist with you, but keep in mind that you should alter it to suit your company and your software.

When I talk about the “app” or “software”, I mean the version, which we are releasing.

Assign all Tasks.

Assign every task in the checklist to exactly 1 person.

The responsible person for a task may change every release, but it is critical, that every task is assigned to someone. If that person only coordinates others doing the task, that is absolutely fine.

The important part here is to have exactly 1 contact person, in case things go wrong or you need a status update.

Software Release Checklist for a mobile App

The following checklist is for a mobile App without a backend. It involves releasing to Google Play Store and Apple App Store.

As some of you may be new to App releases, I have gone into a little more detail here.

Pre-Release

Define new software version. (I recommend Semantic Versioning)
Create release checklist for this software version in our Wiki/Google Drive/etc. It should be visible to everyone involved.
Define target release date. This does not have to be communicated outside of your company. This is mainly for our internal planning.
Define an “end of feature development” for the release. This is the deadline for new features. I recommend at least 1 week before planning your release (2-3 weeks, if releasing for iOS).
A Maintenance Plan exists. Think about where people can report bugs and how you prioritise and fix them. This might include reading app store reviews and a support forum you may have. This can be a simple wiki page with a checklist.
Inform marketing. This might be a team, a person, or yourself. Update your Presskit, prepare a tweet, prepare new screenshots.
We have a release branch or tag in git for this software version. This helps us in case we must test old versions.
Test android app.
Test iOS app.
Upload android app to Google Play Store.
Upload iOS app to Apple App Store.
Update Screenshots & Information in Google Play Store.
Update Screenshots & Information in Apple App Store.
The Apple Review was successful. This step may take several days, even 1-2 weeks if you must fix something. Take this into account when communicating deadlines.
Release android app on Google Play Store.
Release iOS app on Apple App Store.

Post-Release

For software releases without a backend, the post-release checklist is quite short. It basically consists of testing your released app and monitoring customer feedback

Run Regression Tests on released Android App.
Run Regression Tests on released iOS App.
Define process for checking App Store reviews / support forums. Who checks these? How often?

Testing your Software with Style and Structure

Benjamin Justice — Sun, 13 Sep 2020 18:57:57 +0000

After setting up a simple build server in last months article, DevOps Ep. 4: Build Servers, our next step in the DevOps Lifecycle is Testing.

Let’s have a look at structured unit, integration and system testing, inspired by the V-Model used in automotive development.

Note that we are only looking into software verification, i.e. “the software works”. There is also software validation, which verifies, that the software works for a given user or scenario.

What types of tests are there?

When thinking about which types of tests there are, I like referring to the V-Model. When simplified, we can identify the three most important development phases and their verification via tests:

Every Design step is verified within the V-Model (simplified depiction)

In summary software is developed in three stages:

First we gather Requirements.
Next we plan an Architecture (hopefully).
Finally we implement the system.

Now the V-Model defines a verification step for each stage of development, which we will describe in detail in the following chapters.

Unit Testing

Each Unit Test tests one small unit of code.

In object oriented code, these are your classes’ methods.

Most literature also refers to each unit test having a method under test.

Probably the most important part about good unit tests is naming and structuring them, so colleagues can easily understand, what a failing unit test means.

For this purpose I encourage fellow developers to use a naming schema inspired by Behaviour-Driven-Development.

ACTION_WhenCONDITION e.g. authenticateUser_WhenCredentialsAreCorrect
Condition_ThenACTION e.g. CredentialsAreCorrect_ThenAuthenticateUser

While the above naming schema looks good, it is missing a vital piece of information: Which unit is being tested? The solution can be found in one of my favourite articles to date: Structuring Unit Tests on You’ve Been Haacked.

In summary the article recommends creating a test class for every class in your code as usual, but also introduces an additional internal class for every method under test within the class. In C#, partial classes can be helpful if you have a class with many methods.

[TestFixture]public class AuthenticationServiceTest { [TestFixture]public class LoginMethod { [Test]public void CredentialsAreCorrect\_ThenAuthenticateUser() { // Test Code } [Test]public void UsernameIsMissing\_ThenReject() { // Test Code } [Test]public void PasswordIsMissing\_ThenReject() { // Test Code } } public class RegisterMethod { [Test]public void CredentialsAreCorrect\_ThenAuthenticateUser() { // Test Code } [Test]public void UsernameIsMissing\_ThenReject() { // Test Code } [Test]public void PasswordIsMissing\_ThenReject() { // Test Code } } }

When developing Unit Tests, you will sometimes encounter situations, where you depend on other software units in your code.

This is a rather advanced issue and the solution is Mocking. It enables us to create “fake” dependencies for our class under test, but it is worth its own future article.

Integration Testing

Unlike Unit Tests, Integration Tests test multiple units of code working together. They are often realised using frameworks, such as Selenium, to automate usage of small parts of your software.

The important part about Integration Tests is size.

Writing integration tests is often more work than writing unit tests, however they are not very precise. If an integration test fails, you do not immediately know, which software unit is at fault.

As setting up Integration Tests is very dependent on your chosen technologies, I cannot provide a generic example here.

System Testing

Finally System Tests are the final frontier of quality assurance. They test the entire system in a shippable state.

While automation of system tests is theoretically possible, this is a lot of work. So much, that I have never seen automated System Tests in the wild.

As such it is completely normal and okay to have manual system tests.

The only important part about manual system tests, is to have a structure. For each system test, we want to:

define system tests with IDs for easier communication.
document a step-by-step guide with numbered steps, so that anyone can execute the system test.
document each execution of the system tests with
- software version or build number
- time & date
- person performing the test
- test result (Pass/Fail)
- Comments, if any necessary

Although dedicated solutions for system tests exist, such as Azure Test Plans, most of them are expensive. However you can get away by using spreadsheet software. We like using Google Drive Spreadsheets, as it enables us all to edit the documents and protocol our test runs and comments.

While strictly speaking, System Tests only cover the system developed by you, I highly recommend performing these tests on a “production-similar” setup. E.g. Execute your Android Apps System Tests on a real device.

This actually blurs out the lines between System Tests and so-called “End to End” Tests, but that is a good thing. If you are developing a cross-platform application, repeat your system tests for each and every target platform.

Conclusion

We only covered the tip of the ice berg on this subject, but we can follow-up with examples and CI integration in future articles.

For now, it should give you and your team a good overview and allow you to start with simple automated unit testing as well as manual system testing documented in spreadsheets.

You can reach out to me on Twitter or the BrutalHack Discord Server for questions.

The post Testing your Software with Style and Structure appeared first on justice.sh.

Getting Started with Build Servers

Benjamin Justice — Sun, 09 Aug 2020 13:06:31 +0000

For part 4 of our Getting Started with DevOps Series, I want to introduce you to Continuous Integration (CI): Making automatic builds of our newest code available to all team members.

To keep things simple, we will start with a simple build server, which can build a C# hello world project for macOS and linux, verifying your cross-platform compatibility.

Later tutorials will introduce pipelines covering automatic tests and deployments for offline applications as well as server applications.

Creating a Build Server

Before we get into the Bouncer CI setup, let’s get a simple Build server running ourselves.

For this tutorial we will create a quick .NET Core “hello world” on GitHub.

Create a new GitHub Repository (here is mine)
Clone your new repository to your computer
Open a console and navigate to your repository
run “dotnet new console“
commit and push

Choosing a Build Server

There are many good build servers available. All of them have similarities and will get most jobs done.

Travis CI is free to use for open source projects and feature rich.

So it looks like Travis CI is a great place to start.

We also use Travis CI for BrutalHack.Bouncer. You can see our build reports here: https://travis-ci.org/github/BrutalHack/Bouncer/builds

Choosing an Operating System

As developers prefer different operating systems, I suggest we embrace this instead of forcing all developers to use windows or linux.

As a result, your developers are able to use the operating system of their choice. Simply have your build server run the rarest operating system in your team.

Nobody is programming on linux? Then we should build on linux.

Nobody is coding on windows? Then we should build on windows.

Our goal here is to guarantee flexibility for our team and to guarantee that our product will also be more stable on the target system.

Getting Started with Travis CI

As mentioned earlier, we will be using Travis CI with GitHub. So let’s begin by setting up Travis CI! At first we have to follow the guide in the Travis CI Tutorial to authorize TravisCI as GitHub App:

Granting Travis CI access to our GitHub Repositories

Next we create a simple .travis.yaml file in out repositories root:

language: csharp# if your .sln file has a different name, change it here :)solution: ci-example.csproj

This will build a C# solution from the ci-example.sln solution file with default settings.

Commit
Push
Watch Travis CI build your project at https://travis-ci.com/ (here is my build report)

Travis CI building our first commit with travis CI support

If you click on “View Config” in the screenshot above, you will see the default configuration using linux, specifically “xenial”.

The Travis CI linux documentation tells us, that this refers to Ubuntu 16.04 Xenial Xerus.

Cross-Platform Builds

Now let’s complete this tutorial by customizing our build config.

Specifically we want to verify our cross-platform compatibility.

As Travis CI does not support building C# projects on windows, we will only build on macOS and linux within this tutorial.

We can do this by introducing jobs in our .travis.yml file according to the Travis CI Multi OS documentation. Because our C# hello world project is created with .net core 3.1, we must define this version as described in the Travis CI C# Documentation.

language: csharp# if your .sln/.csproj file has a different name, change it here :)solution: ci-example.csproj# Travis CI jobs to run multiple buildsjobs: include: # linux build with Ubuntu 18.04 "Bionic Beaver"# (https://docs.travis-ci.com/user/reference/linux/ - os: linux dist: bionic # .Net Core version 3.1.302 # (https://dotnet.microsoft.com/download/dotnet-core/3.1) dotnet: 3.1.302 # macOS build with "xcode12" image running macOS 10.15.5 with Xcode 12# (https://docs.travis-ci.com/user/reference/osx/) - os: osx osx\_image: xcode12 # .Net Core version 3.1.302 # (https://dotnet.microsoft.com/download/dotnet-core/3.1) dotnet: 3.1.302

After commiting and pushing our new .travis.yml, you will see the new build starting with two build jobs instead of one.

The following screenshot displays my build with the two build jobs.

You can see the full build report here at Travis CI:

Successful linux & macOS builds

Conclusion

Now we know how to setup automated builds, which can verify, that our code works independently of our development machine and cross-platform. Our next episodes will extend our build server to run automated tests and automatically upload releases to GitHub.

Until then, you can reach out to me on Twitter or the BrutalHack Discord Server for questions. I also recommend some further research in the excellent Travis CI documentation.

The post Getting Started with Build Servers appeared first on justice.sh.

Cross-Platform Scripting

Benjamin Justice — Mon, 13 Jul 2020 06:46:04 +0000

In this months DevOps Guide we're getting into scripting. It's just the fastest way to simplify complex tasks. Before you continue, please make sure you are familiar with command line basics.

Just the other day, I wrote a small script to

download multiple swagger json files from services
download the swagger-to-PDF tool
generate a single pdf with all api endpoints

Now developers don't even have to know which tool we use to generate our api documentation. They see the script, run it, and have the pdf file.

Furthermore the tool just automatically identifies which API versions are available.

Cross-Platform PowerShell

Why PowerShell? Well, it is preinstalled on Windows and easy to install on macOS and Linux.

Installing most other scripting languages on Windows is complicated.

My main motivation here is to keep the entrance barrier as low as possible. Enable everyone on your team.

If your team is already familiar with another cross-platform scripting solution (e.g. bash on windows via Cygwin), you already have all you need for our series on DevOps. In that case you can skip this one for the series.

Installation

For this tutorial, we need PowerShell and Visual Studio Code.

PowerShell

For installation steps, follow this guide by microsoft for your operating system.

On Windows, the installation of PowerShell 7 is optional. However, some advanced scripts will require PowerShell 7.

Extra Step for Windows

Before running PowerShell scripts on Windows, you must run Set-ExecutionPolicy Unrestricted.

On macOS and Linux, Unrestricted is the default.

For more information, see microsoft's documentation on Execution Policies.

Visual Studio Code

Now let's download and install Visual Studio Code from Microsoft.

Visual Studio Code offers coding assistance and even debugging functionality for PowerShell. So we will be using visual studio code as free cross-platform script editor within this tutorial.

If you prefer a different editor, I still recommend using Visual Studio Code for this tutorial. After the tutorial, you should check if your preferred editor has the same debugging functionality.

Start Scripting

After getting comfortable with moving around your file system, let's write your first script.

Open Visual Studio Code and create a new file and save it with the .ps1 ending.

This way Visual Studio Code will recognize it as PowerShell script and offer a play button in the top right.

Also I can really recommend reading Microsoft's Guides to Debugging PowerShell with Visual Studio Code to learn how to use Breakpoints and Watches.

She-Bang

As they use different default shells, the first line of your cross-platform script will tell macOS and Linux, that this is a PowerShell script.

pwsh is the command name for PowerShell in macOS and linux.

#! /usr/bin/env pwsh

Hello World

In PowerShell, you have different possibilities to write output.

While Write-Host is okay to give the user information on the state of your script. However, Write-Object, Write-Error Write-Debug and Write-Verbose will be important for advanced scripts.

It's a good idea to be very verbose and always tell the script-user what's happening.

So we can use Write-Host "Copying files, please wait." to display exactly this text to the console.

#! /usr/bin/env pwsh

Write-Host "Hello World."

Variables

Variables in PowerShell are names with a prefixed $ sign.

e.g. $count, $foldername, $date, etc.

#! /usr/bin/env pwsh

$directory = Get-Location
Write-Host "Current directory: $directory"

Objects

The main advantage of PowerShell is its object orientation.

Assuming that your script is called test.ps1, we can read this files properties:

#! /usr/bin/env pwsh
Set-StrictMode -Version Latest

$scriptfile = Get-Item test.ps1
Write-Host "File name: $scriptfile.Name"
Write-Host "File extension: $scriptfile.Extension"
Write-Host "Creation Date: $scriptfile.CreationTimeUtc"

You can use Visual Studio Codes Watch function to examine your script's objects.

We can use the **Watch** function to examine objects in scripts.

As this would be a lot to cover, we will have a closer look at PowerShells object orientation later on. For now, just keep this fact in mind.

Strict Mode

I always recommend enabling Strict Mode in all your scripts.

This is basically your standard second line after the she-bang.

It causes your scripts to abort when using uninitialized variables, non-existant properties etc.

#! /usr/bin/env pwsh
Set-StrictMode -Version Latest

See Microsofts documentation for detailed information on strict mode.

If Else

Microsoft has a super documentation on if-else in PowerShell, including many great examples.

Therefore I only want to show one example here for completeness.

#! /usr/bin/env pwsh
Set-StrictMode -Version Latest

$number = 2;

if ($number -gt 2) {
    Write-Host "$number is greater than 2"
}
elseif ($number -eq 2) {
    Write-Host "$number is equal to 2"
}
else {
    Write-Host ("$number is less than 2")
}

Loops

Microsoft also has a super documentation on loops in PowerShell, so this example is also quite short.

As PowerShell is object oriented, I tend to use ForEach normally.

For or While Loops are quite rare in my scripts.

#! /usr/bin/env pwsh
Set-StrictMode -Version Latest

Write-Host "Listing files in current folder:"
foreach ($file in Get-ChildItem)
{
  Write-Host "- $file (created $($file.CreationTime))"
}

See more more great examples at Microsoft's documentation:

Next Steps

With this basic scripting knowledge, we are able to get started automating in the upcoming episodes of our DevOps Guide.

While most scripts will only run very few commands, these are a few commands that you and your colleagues save every day. And let's not forget the manual errors avoided by your scripts.

We can use them for builds, deployments, tests, project setup, anything!

If you have questions during your first steps in PowerShell, please contact me on Discord, Twitter or Facebook.

Cross-Platform Command Line

Benjamin Justice — Mon, 15 Jun 2020 09:07:59 +0000

The command line can be daunting for many. And yet it is one of the most powerful tools we developers can have. And it's free!

So in this episode I want to help you get comfortable using your command line. You don't have to use it much, but there are some tasks that were just made for the command line. Also, this is a foundation for writing scripts for any operating system.

As part of my Getting Started with DevOps series, this tutorial is cross-platform. We will be using PowerShell on Windows and bash (or zsh, they are compatible) on macOS and Linux.

Feel free to use this article as a reference to look up commands later:

The Basics
Read the Manual
File Operations
The Wildcard
Executing Programs
Make it fun to use!
Thefuck (plugin)

The Basics

First off, start your engines.

Windows: press the start button and search for a program called PowerShell.
macOS: Use Spotlight to launch terminal.app
Linux: Search for an application called Terminal. In Ubuntu, you can also press ctrl+alt+T

Now the first question to answer is: Where are we?

# print working directory
pwd

This is one command for Windows, macOS and Linux. How can this be?

The command line interface in macOS and Linux are identical (bash or another compatible shell like zsh, fish, etc).

You can use most commands in both operating systems.

And while Windows uses PowerShell, they have integrated aliases for unix commands. The output will often differ, but you get nearly the same information.

Now let's navigate around your file system with the following commands:

# list files in directory
ls

# list all files in directory (includes hidden files)
ls -al # macOS and Linux
ls -Hidden #PowerShell

# change directory
cd 

# leave directory / move up
cd ..

# go back to your $HOME directory
cd ~

So we can now navigate around our file systems, but typing the folder names takes long. Time to try out tab-completion.

While typing anything in your terminal, you can often press tab to auto-complete your command, filename or directory name.

Just a few examples to get you started:

# cd to directory "Documents"
cd Doc
# => cd Documents

# list hidden files in PowerShell
ls -Hi
# => ls -Hidden

Read the Manual

There are many commands coming up and both PowerShell and bash/zsh have manuals you can read on every single command.

After all, this is just your beginning ;)

# Show manual in PowerShell
Get-Help  -Full

# Show only examples in PowerShell
Get-Help  -Examples

# Show manual in macOS/Linux
man 
# Scroll with arrow keys up/down
# Close with Q

File Operations

# Create a new file
touch 

# Display file contents
cat 

# list target directory contents
ls 
# e.g. ls ~/Documents

So now that we can navigate through our file system, it‘s time for some interaction. Creating, Copying, Moving and removing files are the three basic operations I use everyday.

# Move a file 
mv  /
# e.g. mv Documents/photo.jpg Pictures/

# With the move command you can also rename files
mv  /
# e.g. mv Documents/photo.jpg Pictures/holiday-photo.jpg
# e.g. mv photo.jpg holiday-photo.jpg

# Remove a file
rm

Now that we know how to work with files, we can alter these commands slightly to work with directories.

# Move a directory 
mv  /
# e.g. mv Scanned-Pages ~/Documents/

# With the move command you can also rename directories
mv  
# e.g. mv Scanned-Pages Scans

# Remove an empty directory
rmdir 

# Remove a directory with all its contents (careful with this one!)
rm -rf

Take some time to get comfortable with these commands before you move on. The cool stuff is just ahead.

The Wildcard

# Show the content of all .txt files
cat *.txt

# Move Photo-london.jpg, Photo-tokio.jpg, Photo-berlin.jpg etc to parent directory
mv Photo-*.jpg ../

Executing Programs

Now the last part missing is: How do I execute a program on the command line? Of course, globally installed software can be run by simply executing the command. But local files? They sometimes need execution permission (macOS and linux only)

# Add execution permission to file on macOS/Linux
chmod +x 

# execute a local file
./
# Example: list connected devices with android developer tools
./adb list devices

Beware that the above command sets execution permissions for all users on your computer. If you are managing permissions for a file outside of your personal directory or generally want to learn more about your unix/linux permissions, tutorialspoint explains it well.

Make it fun to use!

Now I would love to share an easy-to-setup terminal, that is really fun to use. Including bells and whistles!

First, let‘s get a good terminal Emulator that supports tabs.

Just like in my browser, I often use multiple Terminal Tabs (e.g. for working in different Git repositories)

Windows: Windows Terminal
MacOS: iTerm2
Ubuntu Linux: Guake

Okay. Now that the terminal emulator (the window) is easy to rich and offers tabs, support for ctrl+f/cmd+f text search, copy-paste and more, it‘s time to upgrade what‘s inside of that window.

Meet Starship.

Starship is a feature-loaded command prompt, which automatically shows you the following information and more without you asking for it:

Git Status
Current User
If the last command returned an error
Current directory’s NodeJS/Python/Ruby/Rust/Dotnet/Java/etc version
Current Kubernetes/Azure/AWS/etc environment
command duration

Just check out the gif on its website. it shows it all.

As I also like the features oh-my-zsh brings to the table, I use iTerm2+oh-my-zsh+spaceship, which is very similar to starship but only available for zsh. If you‘re interested, I might go into detail on my personal setup.

Thefuck (plugin)

Another Plugin I love using is thefuck. Yes, that‘s its name. And it does what you think it does: It adds support for writing fuck when you messed up your last command.

# try to clone the bouncer repo
git clpne git@github.com:BrutalHack/Bouncer.git
# => git: 'clpne' is not a git command. See 'git --help'.

# The most similar command is
#  clone

# correct the previous command
fuck
# => git clone git@github.com:BrutalHack/Bouncer.git [enter/↑/↓/ctrl+c]

My most common case: When I create a local git branch and try git push, git says that I must first setup your new branch to track a remote new branch.

I do not know this command, but instead write fuck, which then suggests the correct command.

For those of us working for clients, we can change the word to „carp“, „meh“ or something funny.

# push new "my-branch" to the git repository
git push
# => fatal: The current branch new-branch has no upstream branch.
# To push the current branch and set the remote as upstream, use
#
#    git push --set-upstream origin my-branch

# correct the previous command
fuck
# => git push --set-upstream origin new-branch [enter/↑/↓/ctrl+c]

Getting Started with DevOps

Benjamin Justice — Sun, 17 May 2020 16:00:00 +0000

DevOps. This buzzword is thrown around a lot and can be hard to understand at first. So what does it mean?

Within this series I'm want to break it down for fellow developers step-by-step:

What is DevOps and how can you get started?

The name DevOps says a lot, as it's a combination of "Development" and "Operations".

It basically stands for a mindset of embracing the entire software development process. Including planning, releasing and operating the software product.

Sounds like a lot of work? That's why DevOps Engineers automate anything they can.

As an example, here are a few things I implement within my projects to embrace DevOps:

PowerShell scripts to install tools and setup your project

New co-workers don't have to waste 1-2 days installing software and configuring their system. Get to the fun parts!
Deployment scripts

These can be small local PowerShell scripts that upload your website via FTP or they can be actual build scripts in a system like Azure DevOps, GitHub Actions or Travis.
File conversion scripts

Do colleagues need to convert lots of files? E.g. sound files from .ogg to .wav? I'll create a script using ffmpeg for that. Start the script, have a cup of coffee, 100 sound files converted. No tedious clicking.
Monitoring alerts

Is your server becoming crowded? I like getting an e-mail when we reach 60% load. This gives me enough time to plan ahead without checking monitoring systems manually.
Define Processes

Do you have a step-by-step guide for releases, user tests and other processes? I highly recommend them. A wiki is the best place to document them.

This is a small taste of what we will learn during this series, but let's take a step back.

The DevOps Lifecycle

The DevOps mindset can be applied throughout the entire lifecycle of your projects. You've probably come across this image online already:

The DevOps Lifecycle

As you can see, the only prerequisite to implementing DevOps is working in iterations.

I have broken down the DevOps Lifecycle into chunks and will offer a deep look at each one of them:

Plan

While planning your project, you should consider all phases of your products life cycle, not just development.
Code

Developers want to code. They don't want to reinvent wheels or spend a day setting up the project and its databases.
Build

Build Systems speed up and simplify your build process. However they can also provide additional services, such as static code analysis or uploading binaries for your testers.
Test

Most Tests can be automated. Our goal is to reduce, but also improve your manual tests.
Release

A release is much more than just uploading your built software. There is much to plan: You have to validate your built software, plan your release (frontend and backend), migrate your databases to the new version, and more. Let's optimize it all.
Deploy

This is probably the most popular case. Manual deployments can take so much time. Once you automate them, you will never look back.
Operate

Most systems do not need routine maintenance. But they do require automated backups, SSL certificate renewals, software updates and emergency plans.
Monitor

Of course we can monitor our servers and see if they are still running. However, we can answer many more questions: How many users are using our servers? How is our growth? When do we need to scale? And can we scale automatically?

I will also include excursions where I see them as useful (expect a crash course on cross-platform scripting).

Are there any DevOps topics you would like me to write about?

I'm open for questions and suggestions on our Discord, Facebook or Twitter.

Forem: Benjamin Justice

One-Click Deployments for Small Projects

Writing a Deployment Script

Step 1: What do we need?

Step 2: Where do we need it?

Step 3: How do we transfer it?

Step 4: Script it!

deploy-dev.sh

deploy-prod.sh

Conclusion

One Easy Trick to Manage Your Software Release

What is a Software Release?

The Software Release Checklist

Assign all Tasks.

Software Release Checklist for a mobile App

Pre-Release

Post-Release

Further Reading

Testing your Software with Style and Structure

What types of tests are there?

Unit Testing

Integration Testing

System Testing

Conclusion

Getting Started with Build Servers

Creating a Build Server

Choosing a Build Server

Choosing an Operating System

Getting Started with Travis CI

Cross-Platform Builds

Conclusion

Cross-Platform Scripting

Cross-Platform PowerShell

Installation

PowerShell

Extra Step for Windows

Visual Studio Code

Start Scripting

She-Bang

Hello World

Variables

Objects

Strict Mode

If Else

Loops

Further Reading

Next Steps

Cross-Platform Command Line

The Basics

Read the Manual

File Operations

The Wildcard

Executing Programs

Make it fun to use!

Thefuck (plugin)

Further Reading

Getting Started with DevOps

The DevOps Lifecycle