fabiochiu/medium-articles huggingface dataset:
There is no “there” to get to
By: Natasha Sniehirova
Tags: Life, Thoughts, Opinion, Experience, Advice

It feels like in society there is this end goal of being happy and so we must compete and race to get “there”.

But there is no got “there” or constant state. Life will forever contain ups and downs and things will always change.

There is no I “made it”

I graduated school didn’t feel anything really. Then I graduated university and found a job and still was like? Where is that feeling?

And I realized there is no I “made it”. There will always be more to learn and more work to do and I will never finish. The goal isn’t to finish. It’s to live.

There is no end “point”

I thought there would be a definitive point where I “made it” and finally got “there”.

But there is no end “point”. Life is a path without a real end point — it’s leads us places and then leads us somewhere else. And actually we don’t have to reach that point in order to have a meaningful, beautiful, and whole life.

This is something I’ve been thinking about a lot for the past few days and I thought it would be great to put my thoughts into words and add a reminder to it — stop waiting, stop holding your breath and enjoy the present moment.

Let me know how this lands with you!
What a Drill!!?
By: Divyosmi Goswami
Tags: Theft, Experience, House, Creepy, Creative

What a Drill!!?

Photo by Claudia Soraya on Unsplash

Dear reader,

Yesterday, I and my family were watching a movie and after watching some 15 minutes I felt thirsty, I told everyone to pause the film and wait for me. I am afraid of the dark. I afraid walking tiptoe and turned on the light and then I took some water in the glass and drank it, it felt like the glass was waiting for me. After drinking water I was going to the room but I don’t know my vision went straight towards the main door of our flat and I found it only closed and if we wanted we could only turn the knob and open it and the main lock was not locked. I was as stiff as a statue for some time and now I was thirsty like a desert. I called my parents. The fear was that someone might enter the house and we could not hear because the sound of tv was loud.

We started our search, all of us with some weapon, I with big scissors, my sister a fork, my mother with nothing and my father well with a knife. My mother was given the task of searching and I helped her if we found someone I would be there to help mom and myself. My papa and sister would be searching for some other side of the house. We searched every mortal thing in the house. We were really scared and it was a creepy experience for me.

Then suddenly my father caught a thought that it there any sign of soap on key. The person could have made a print of the key. We also checked and tested it. And why? Forget that God is there. By God’s grace, nothing happened. I was afraid that whole night.
IX #035 — The Experience Newsletter
Tags: Experiential Marketing, Ritual, Desing, Experience, Experience Design

A weekly grackle-eyed scry into the best news, scholarship, case studies and more from the ever-evolving world of experience.

Subscribe to IX

Comprising colorful rammed earth domes, this vibrant multipurpose communal residence has been designed by ZAV architects.

I. During a time of social distance, a colorful village designed for communal living is being built in Iran.

II. The squishy mud of warm-data: a beautiful piece from Nora Bateson on the intangibles of experience.

III. Braniff airlines flight-attendant college is being turned into a boutique hotel.

IV. The curator of “Designs for Different Futures,” Michelle Miller Fisher, discusses the state of things in 2020.

V. eBay opens the first-ever drive-thru ‘authentication station’ in LA.

VI. A 19th century arch in Prospect Park underwent an half-million dollar remodel.

VII. Nostalgic Americans Are Making Tru-Tone Retro Lights an Unlikely Holiday Hit.

VIII. Apple Fitness+ launches on December 14th and here’s everything you need to know.

IX. Kelley Blue Book launches island in Animal Crossing: New Horizons.

Grackle is an experience design studio and consultancy specializing in designing immersive experiences that meld people with products, places, brands, and each other. Get in touch
IX #036 — The Experience Newsletter
Tags: Experiential, Design, Experience, Studio, Marketing

A weekly grackle-eyed scry into the best news, scholarship, case studies and more from the ever-evolving world of experience.

Subscribe to IX

A discussion focusing on finding the story in immersive settings where users can interact with structured worlds.

I. How fear and disgust drive consumer behavior.

II. A discussion on finding the story in immersive settings where users can interact with structured worlds.

III. The tides within us — the science behind the Experience.

IV. Three ways retailers are re-thinking the role of brick-and-mortar stores.

V. Before most brands had sonic signatures, IBM had a song book.

VI. We were going to put a link here about some “totally immersive virtual experience,” but then found this poem about a guy’s totally immersive pony experience and realized that reading it offered a much more immersive virtual experience than the other thing.

VII. Launch of the Macallan experience at the Raffles Hotel in Singapore.

VIII. The neuroscience of peripersonal space. Nice.

IX. Some Iroquois folk tales to tuck your kids (or yourself) into bed with tonight.

Grackle is an experience design studio and consultancy specializing in designing immersive experiences that meld people with products, places, brands, and each other. Get in touch

WRITTEN BY

An experience design studio and consultancy specializing in experiences that meld people with products, places, and brands.
Liberal Arts Blog — Gratitude is the Sun
By: John Muresianu
Tags: Gratitude, Experience, Mnemonic, Values, Liberal Arts Blog

Liberal Arts Blog — Friday is the Joy of Art, Architecture, Design, Film, and All Things Visual Day

Today’s Topic — Gratitude is the Sun

Eureka! About 5 years ago, I realized that the best one word answer to the question, “What is the most important thing you learned in your life?” is “Gratitude.” Then perhaps 2 years ago, I ran with the idea that the best way to remember what matters most is to harness your visual field — specifically the blue sky (gratitude), the white clouds (kindness), and green plants (truth). This morning i decided that I was wrong. The best mnemonic, the best metaphor for gratitude is not the blue sky. It is the sun. Experts — please chime in. Correct, elaborate, elucidate.

THE SUN IS LIGHT, WARMTH, ENERGY — no sun, no life

1. Just as, in the words attributed to Cicero, “Gratitude is not only the first of the virtues but the parent of all the others.” So the sun is the source of all light, warmth, and energy.

2. Imagine gratitude as the sun with arrows representing the rays leading to all the other virtues — from kindness to courage to wonder to prudence to temperance to whatever other values you prize most.

3. Imagine gratitude as the sun at the center of the Buddhist wheel with eight spokes (rays) leading to right thought, word, deed, at home, at work, at play, in normal times, in emergencies.

NB: Above is the Sower by Van Gogh, 1888. What is your favorite depiction of the sun in art, ancient or modern, from anywhere on the earth?

EVERY SUN RISE, EVERY SUN SET IS A THING OF INCOMPARABLE BEAUTY

1. The most amazing show on earth happens twice a day!

2. Amazing grace, how sweet the sound!

3. How often do you savor them?

NB: Above is “Impression Sunrise” Claude Monet, 1872

THE NIGHT’S SUN IS THE MOON

1. Moon rise and moon set are not as dramatic as sun rise and sun set but, still, not to be missed. Still magical.

2. And in a way, more interesting, as the moon is constantly changing shape.

3. How exactly does that work? If gratitude is the sun, to me the matrix is the moon — the perfect metaphor for critical thinking.

NB: To me this gives the Tao Symbol new meaning — the Yang (sun) of gratitude and the Yin (moon) of critical thinking. The essence of education is a balance of knowledge (the primacy of gratitude) and process (critical thinking). More on this in today’s other post.

Sun

Solar symbol

Helios

Ra

Solar deity

List of solar deities

For the last three years of posts organized by theme:

PDF with headlines — Google Drive

YOUR TURN

Please share the coolest thing you learned recently or ever related to art, sculpture, design, architecture, film, or anything visual.

This is your chance to make some one else’s day. And to cement in your own memory something cool or important you might otherwise forget. Or to think more deeply than you otherwise would about something that is close to your heart.
To 2001, the year I still dread- 1
By: Mariam Adedoyin Adeyeye
Tags: Grief And Loss, Transport, Experience, Travelling, Journey

To 2001, the year I still dread- 1

Grief, as they say, come in different forms. There are times that it tugs at us, so hard that we choke under its weight. Times when we wonder if there’d ever be a way out. I have seen grief, I have experienced it and I have choked.

2001 was a year that I got shook to my core, a year that I questioned the very essence of my being. It was a year that everything changed for my family.

The year was pretty smooth until March when my mother decided to take my younger brother and I to her hometown for the holidays - I was excited about this particular trip because my mother had always been a strict one and I dreaded being alone with her during the holidays. When she suggested that we change environment for a while, you do not want to picture the happiness that coursed through me, little did I know that it was going to be short lived.

On the 31st of March, 2001, my mother, with out baggage and myself plus younger brother whom was just a little above 2 years went to the Ile Ife park at Agodi Gate- there were two buses on turn and one had just one more passenger to get filled up. I still can’t picture if it was a dream that I had earlier heard or I was just being the ‘emere' that my mum referred to me as but I sternly warned my mother not to enter this bus that was going to leave soon. In fact, I wept, tugging at her skirt and begging that we became the first passengers in the other bus but not only did she shout at me in her usual way, the other passengers that were already eager to leave the park (if only they knew it was going to be their last trip) beckoned at us to go with them and yes, we did.

Out seat was right behind the drivers’- I remember the faces of our neighbours on that row, there was a man right by the window(this man swapped places with us so that it would be easier for my mother to ‘lap' my brother and I). There was another woman, baker that had thus massive wedding cake to deliver for a wedding the following day in Ife. She was the most impatient of us all because she was getting late and didn’t want to exceed her deadline- GSMs were not that common at the time(only the selected few were just starting to test the waters) so there was no way for her to reach the bride that she was on her way. Payments were made, the agberos removed their shares and we left the city of Ibadan, little did we know that none of us was going to return as whole beings.

We set out, not knowing that this journey was going to rob of us happiness, sanity and good health in a matter of hours to come.
Software Testing
By: Jeffrey Chen
Tags: Unit Testing, Continuous Integration, Testing, Test Automation, Integration Testing

Good Testing Practice

Define the expected result clearly in each test

You should well understand the logic and define what’s the result of the test case in normal case.

Avoid unreproducible testing

It’s hard to investigate the defect when the test case failed if the test is unreproducible.

Write test cases for both valid and invalid input conditions

Testing with invalid input can help you to exam your error handling logic. Users always act unexpected.

Thoroughly inspect the results

The test result may return multiple values, make sure the whole result is same as your expectation.

Choose right people to do the test

Different test has different purpose, find the best people to do the test.

Consider testability when you develop the system

If you system is hard to test, it will cost you more time to find the defects. Then, it’s hard to grantee the system quality.
A technical deep dive into processing €5 million in donations in 2 hours using Cloudflare Workers
By: Peter Vanhee
Tags: Cloudflare Workers, Continuous Integration, Serverless, Cloud Native, Serverless Architecture

A technical deep dive into processing €5 million in donations in 2 hours using Cloudflare Workers

A deep dive into the serverless architecture behind the Late Late Toy Show donation platform and the challenges we faced in putting it together in just a couple of weeks. Peter Vanhee Follow Dec 7, 2020 · 7 min read

For an introduction to our serverless platform for RTÉ’s Late Late Toy Show, see this article.

In this article, we’ll give you a factual blow-by-blow replay of the evening, together with a deep dive into the technology under-pinning it all. Not everything went according to plan (does it ever?), however the RTÉ Toy Show Appeal was a resounding success.

The Project

The brief for the first ever commercial project for our agency, We are Serverless was as follows:

Build a donation platform for Ireland’s most popular TV program, RTE’s Late Late Toy Show, and have it ready to go within four weeks.

With this being the first time that there would be a donation ask on the Toy Show, we had no idea of how much money would be raised, nor how many viewers would be converted to donors. We only knew the following:

estimated audience of 1.5 million viewers in Ireland plus Irish diaspora from 130+ countries globally

we should allow for effortless scaling, from nearly zero activity to thousands of requests per second

potentially handle hundreds of transactions per second

build it lean; the more code and complexity the application itself would have, the longer it would take to build and the harder it would be to operate at scale

Building the platform

For our first challenge, we had to decide on the underlying architecture for the platform, we settled on Cloudflare Workers.

As far as serverless platforms go, Cloudflare Workers might be less well known than AWS Lambda. However, they would allow our code to run on Cloudflare’s global edge network rather than on regional instances. Cloudflare, unlike any other cloud computing services, doesn’t use containers or virtual machines, but V8 isolates, the technology created by the Google Chrome team to run javascript in the browser. Practically for us this meant code would run closer to our end-user making the request, and invocations wouldn’t incur any cold start, which can run into the 100s of ms.

The results from our load testing using serverless artillery, Grafana and InfluxDB were promising. We simulated slamming the site with up to 300 donation journeys for a few minutes and saw request latencies not higher than 416ms for 9 out of 10 of the requests , and on average only 77ms.
CIRCLECI PIPELINE TO DEPLOY ANGULAR APP TO FIREBASE
Tags: Continuous Integration, Angular, Firebase, DevOps, Circleci

In this section we can see the first part of the build. Here we are running inside the docker image circleci/node:12.11.1-browsers all the steps that allow us to checkout the code, restore the installed packages from the cache (in the first build of course will be empty), making an npm install and then save the node_modules folder in the cache. As we can see, we use the package.json checksum to generate the key for our cache (the key changes only if an update is made in the package.json).

version: 2.1

jobs:

build:

working_directory: /tmp/workspace

docker:

- image: circleci/node:12.11.1-browsers

steps:

- checkout

- restore_cache:

key: dependencies-{{ checksum "package.json" }}

- run:

name: Install dependencies

command: npm install

- save_cache:

key: dependencies-{{ checksum "package.json" }}

paths:

- ./node_modules

In the second part we install and use the angular cli to build and run the tests. Thanks to the persist_to_workspace we can save the output of the build that will be used in the next job, the deploy.

- run:

name: Install Angular cli

command: sudo npm install -g @angular/cli > /dev/null

- run:

name: Build uat application

command: ng build --configuration=prod

- run:

name: Test application

command: ng test -- --watch=false

- persist_to_workspace:

root: /tmp/workspace

paths:

- dist

So here the deploy job. The first step after the checkout will be the attach_workspace to have access to the dist folder containing our build. In order to deploy to firebase we have to install the firebase-tools (if not already listed in our dev dependencies) and use the firebase deploy command with the token already created.

deploy:

working_directory: /tmp/workspace

docker:

- image: circleci/node:12.11.1-browsers

steps:

- checkout

- attach_workspace:

at: /tmp/workspace

- run:

name: Install Firebase

command: npm install -D firebase-tools

- run:

name: Deploy to firebase prod

command: ./node_modules/.bin/firebase deploy --token=$FIREBASE_TOKEN --only hosting:prod

Last but not least the workflow section. We declare how we need to run the steps described until now. In particular we run the pipeline only for the master branch, and the deploy after a successful build.
We’re Now Live With LambdaTest TeamCity Plugin
Tags: Teamcity, Continuous Delivery, Java, Continuous Integration

2020 has proved turbulent for many businesses. But with your support, we’ve weathered the storm surprisingly well. And since this year is about to end and the holiday season is upon us, we thought it is time to show our loyal customers our appreciation and bestow them with gifts and love. So, before you pull out your cozy pullovers, start making that delicious eggnog and unwrap your presents, let us drop in our share of holiday gifts to your ever-growing pile. This time, we have a brand-new TeamCity plugin to introduce!

Let’s get to it, shall we?

TeamCity Plugin

TeamCity is a Java-based CI/CD tool created by JetBrains, the producer of other useful tools such as PyCharm, IntelliJ Idea, RubyMine, ReShaper, and more. It offers source control, build chain tools, and detailed build history — features are not available in a free tool like Jenkins (Read: TeamCity vs Jenkins).

It can be installed on Windows and Linux servers. It also provides support for the .Net framework and can be integrated into IDEs such as Visual Studio and Eclipse. TeamCity offers CI “out of the box” and assists numerous languages (Ruby, .NET, Java, and several others). It contains JetBrains to back the tool up with support and records wisely. Its slick GUI and simple to use attributes make it more pleasant for some new to CI.

Since TeamCity is one of the most in-demand CI/CD tools, we’re now live with our exclusive TeamCity plugin to help you integrate your projects seamlessly from our dashboard. This plugin will help you manage your LambdaTest credentials, write and execute tests directly on the LambdaTest platform, and test your local, internal, dev, or stage environments securely with the help of Lambda Tunnel. You can get this plugin from JetBrains Marketplace.

Now you can-

Configure your project to use LambdaTest TeamCity Plugin

Execute your tests on LambdaTest

Configure Lambda Tunnel for local testing

Test privately hosted site with the help of TeamCity Plugin

For information on making the most of this plugin, you can check out our support documentation on TeamCity Plugin Integration.

Zoom In Feature For iOS Devices

You can now zoom in during your real time testing sessions to check out any flaw or break in your web page’s UI. We are currently offering this feature only for iOS simulator-based devices and is supported in WebRTC sessions only. But we will soon be adding this zoom in feature to more devices.

Wrapping Up!

So this is where we end with our product update for the month of December. We hope this TeamCity plugin will make it easier for you to carry out testing with more ease on our platform. Remember that we are working non-stop to bring out the best integrations, plugins, and features to make cloud-based testing more seamless than ever. Also, we’d always love to hear from you to understand where we can get even better. Nobody can help us improve if not our customers, right?

We will be coming back with a lot of new product updates soon, so stay tuned to this section to get regular updates!

Author Kritika Murari
Continuous Integration & Deployment for Android apps
Tags: Android App Development, Continuous Integration, Android, Continuous Delivery, AndroidDev

Delivering Android apps can be a pain in the neck.

Preparing builds, signing the release, messing with the store — all this stuff require extra effort that could well be invested into actual coding.

But what if the whole process looked like this:

Pipeline example

This is called Continuous Delivery: a process that allows developers to produce valid builds ready to be published to the app store on a single push to branch.

And this is exactly what Buddy does.

In this guide, we are breaking it down to a simple list of how-to steps and show you how easy it is to implement even advanced DevOps strategies with Buddy.

Step 1: Build APK on every push

Before you start The core of Continuous Delivery is version control. Buddy supports all popular Git hosting providers, including GitHub, Bitbucket and Gitlab. You can also use your own private server of host code directly on Buddy. If you are new to Git, this guide will get you started in no time.

The basic concept of Buddy’s development automation are Pipelines. Pipelines have steps called actions. There are three dedicated actions for Android Continuous Delivery:

Build APK

Sign APK

Publish to Google Play

Let’s start with adding a pipeline that will be executed on every push to the Staging branch:

Adding new pipeline

Once you configure the pipeline, Buddy will ask you about the first action to be added to the newly created pipeline. Select the Build APK action from the Android section.

First, Buddy asks about the SDK Version and Build Tools Version to be used for building the APKs:

Action details

On the next screen you can adjust build commands in case your project requires other steps besides ./gradlew assembleRelease (e.g. unit tests):

Run tab

Also, if you need to preinstall additional dependencies besides SDK and Build Tools, you may add them in the Environment Customization tab:

Environment customization

If you are good with the configuration, just hit the Add this action button.

Congratulations! From now on, Buddy will automatically build the APK on every push to the Staging branch.
Heroku’s CI TAP Output
By: Muyiwa Olu
Tags: Heroku, Continuous Integration

Heroku mentions TAP support for running tests within their CI environment.

If the executed test scripts emit TAP-formatted output to STDOUT, individual passes and failures are counted and displayed in the test run’s UI.

Heroku indicates that the individual tests are displayed on the UI if the output is TAP compliant.

They don’t mention what this UI looks like, or how to know if the output is correctly being accepted as valid TAP output to get the enhanced UI.

I’ve taken some screen grabs of the before and after to save you some commits.

Without TAP

An error Continouous Integration build without TAP enabled.

With TAP
Cake v1.0.0-rc0002 released
By: Cake Build
Tags: Dotnet, Continuous Integration, Csharp, Release Notes, DevOps

Version 1.0.0-rc0002 of Cake has been released.

This is the second, and probably last, pre-release version of Cake 1.0. Focus in this release has been to bring Cake Frosting up to speed, align it with the Cake script runners and bug fixes.

Major new features

Frosting NuGet tool resolution

Align Cake Frosting CLI with Cake script runners

Bug fixes

Addin recommended Cake version set to 1.0

We’ve chosen to release 1.0 as a pre-release to NuGet and Chocolatey, so we and the community can more easily test and ensure that our 1.0 release will be as stable as possible. It will also enable us to see if there are any steps you need to take to adapt your scripts for 1.0, and for us to see if there’re any unintended breaking changes, by testing as many addins, modules, and recipes as possible.

Breaking changes in Cake Frosting

CakeHostBuilder has been removed. With Cake.Frosting 1.0 can be used directly to create the object.

With Cake.Frosting 0.38.x:

With Cake.Frosting 1.0:

Addin recommended Cake version set to 1.0

In preparation for the 1.0 release, we’ve now set the recommended version of Cake.Core for addins to target to 1.0.

This won’t break the build but you might see warnings like below when Addins/Modules are loaded.

The assembly 'Cake.DotNetTool.Module, Version=0.4.0.0, Culture=neutral, PublicKeyToken=null' is referencing an older version of Cake.Core (0.33.0).

Addin authors can start preparing for the 1.0 release by starting to build against Cake.Core version 1.0.0-rc0002.

Upgrading

See Upgrade instructions for documentation about breaking changes in this release.

Contributors

Contributions were included from:

Full details of everything that was included in this release can be seen below.

Issues

As part of this release we had 14 issues closed.

Breaking change

#2930 Increase potential breaking change property.

Increase potential breaking change property. #2904 (Frosting) Tool installer should respect configuration.

Feature

Improvement

#2838 Add MakeRelative alias to DirectoryPath and FilePath.

Add MakeRelative alias to DirectoryPath and FilePath. #2886 (Frosting) Support all commands that Cake does.

(Frosting) Support all commands that Cake does. #2893 (Frosting) Align command line parsing with Cake.

(Frosting) Align command line parsing with Cake. #2892 (Frosting) Add ANSI console.

Documentation

Build

#2980 Update to .NET 5 SDK 5.0.101.

Update to .NET 5 SDK 5.0.101. #2929 GitReleaseManager milestone should use SemVersion.

GitReleaseManager milestone should use SemVersion. #2928 Cake.Frosting and Cake.Frosting.Template not pushed to NuGet.

Cake.Frosting and Cake.Frosting.Template not pushed to NuGet. #2900 Update to .NET 5 SDK “RTM”.

Bug
Announcing public beta of Cirrus CI Persistent Workers
By: Fedor Korotkov
Tags: On Premise, Continuous Integration

Cirrus CI pioneered an idea of directly using compute services instead of requiring users to manage their own infrastructure, configuring servers for running CI jobs, performing upgrades, etc. Instead, Cirrus CI just uses APIs of cloud providers to create virtual machines or containers on demand. This fundamental design difference has multiple benefits comparing to more traditional CIs:

Ephemeral environment. Each Cirrus CI task starts in a fresh VM or a container without any state left by previous tasks. Infrastructure as code. All VM versions and container tags are specified in .cirrus.yml configuration file in your Git repository. For any revision in the past Cirrus tasks can be identically reproduced at any point in time in the future using the exact versions of VMs or container tags specified in .cirrus.yml at the particular revision. Just imagine how difficult it is to do a security release for a 6 months old version if your CI environment independently changes. Predictability and cost efficiency. Cirrus CI uses elasticity of modern clouds and creates VMs and containers on demand only when they are needed for executing Cirrus tasks and deletes them right after. Immediately scale from 0 to hundreds or thousands of parallel Cirrus tasks without a need to over provision infrastructure or constantly monitor if your team has reached maximum parallelism of your current CI plan.

For some use cases the traditional CI setup is still useful. However, not everything is available in the cloud. For example, Apple releases new ARM-based products and there is simply no virtualization yet available for the new hardware. Another use case is to test the hardware itself, since not everyone is working on websites and mobile apps after all! For such use cases it makes sense to go with a traditional CI setup: install some binary on the hardware which will constantly pull for new tasks and will execute them one after another.

This is precisely what Persistent Workers for Cirrus CI are: a simple way to run Cirrus tasks beyond cloud! Run Cirrus CI on any hardware including the new Apple Silicon, any other ARM or even things like IBM Z!

Airbnb mobile CI setup in 2017: Mac Pros in the office

Please follow documentation in order to configure your first persistent worker and please report any issues/ask question either on Twitter or through GitHub issues.
สร้างเว็บไซต์บน Kubernetes ง่ายๆ โดยไม่ต้องวางระบบเองด้วย DigitalOcean App Platform
Tags: Kubernetes Cluster, Continuous Integration, Infrastructure, Kubernetes, Automated

Learn more. Medium is an open platform where 170 million readers come to find insightful and dynamic thinking. Here, expert and undiscovered voices alike dive into the heart of any topic and bring new ideas to the surface. Learn more

Make Medium yours. Follow the writers, publications, and topics that matter to you, and you’ll see them on your homepage and in your inbox. Explore
Debug Docker builds in Travis CI
By: Ronny Roeller
Tags: Continuous Integration, Travis Ci, Docker, Software Development, DevOps

Debug Docker builds in Travis CI

We use Travis CI to build our services and apps. Each repository contains a .travis.yml file with all steps for Travis to execute during build time. Having the build instructions in a Travis specific config file means that builds aren’t possible during a Travis outage. Not ideal.

We therefore moved all our build instructions into a Dockerfile , which gets triggered by a very simple .travel.yml . With that, we can run the same build process in Travis and on any other machine (including each developer’s machine).

Of course, everything comes with a downside. For the Docker approach this is debugging of builds that fail only on Travis — but not locally. One needs to capture the build image created on Travis to debug it.

Here are the steps on how to do this:

1. Prepare Travis container

First, ensure that the step in question doesn’t completely crash docker build by returning a non-error exit code, e.g. in case the npm run build step in the Dockerfile fails:

RUN npm run build; exit 0

Next, start the Travis build in debug mode (see howto) and execute in the shell the prepare phases:

$ travis_run_before_install

$ travis_run_install

$ travis_run_before_script

2. Execute Travis build phase

Then find out the commands executed during the Travis build phase — without running it:

$ type travis_run_script

travis_run_script is a function

travis_run_script ()

{

travis_cmd docker\ build\ -t 12345678.dkr.app\ . --echo --timing --event script;

travis_result $?;

:

}

Now, we can execute this command directly in the shell. The _docker_args environment variable passes additional arguments to docker build. --rm=false and --force-rm=false stop Docker from removing any intermediate containers:

$ _docker_args="--rm=false --force-rm=false" docker build -t 12345678.dkr.app .

In the output of this command, take note of the Docker image ID using during the failing step, e.g.:

Step 14/26 : RUN npm run build; exit 0

---> Running in 683dae386bdc

3. Capture Docker build image

Next, we have to copy the failing Docker build image to a place were it can be accessed from outside. We use AWS ECR for that:

$ docker commit 683dae386bdc 123456789012.dkr.ecr.eu-west-1.amazonaws.com/my-app:bug

$ docker push 123456789012.dkr.ecr.eu-west-1.amazonaws.com/my-app:bug

4. Run build image locally

Finally, we can run the captured image in a local Docker container and debug it there further:

$ docker run — rm -it — entrypoint sh 123456789012.dkr.ecr.eu-west-1.amazonaws.com/my-app:bug

Happy debugging!
CI/CD for Automation Testers
Tags: QA, Continuous Integration, Continuous Delivery, Continuous Deployment, DevOps

CI/CD pipeline or Continuous Integration/ Continuous Deployment is the backbone of today’s app deployment process.

A pipeline is a workflow which consist of multiple jobs to deliver the software to the customers.

Version control > Build > Unit tests > Deploy > Automation tests > Deploy to production

Above representation is the basic flow of the whole pipeline process that represents how software will move along the different stages before it reaches the customer.

As an Automation tester, we majorly needs to focus on Continuous Integration.

Continuous Integration process after the planning stage. In this stage, developer integrate their code very frequently (multiple times a day) in some central source code repository. Each integration is verified by automated build and automated tests.

Major key benefit of continuous integration

1. Continuous feedback on the recent changes in code.

2. Detects the errors early and quickly.

3. Cost effective

4. Decrease testing time and QA team can invest more time in building quality culture.

Continuous delivery VS. Continuous deployment

Continuous delivery is an extension to the Continuous Integration process.It deploys all the new code to the testing or production environment after going through the automated build stage.In other words, we can set an automated release process as per our requirements(daily, weekly or fortnightly) with just a click of a button.

However, Continuous Deployment is an add-on to the Continuous Delivery process. In this every change that passes all the stages of the pipeline is released to the customers.

Cheers!! 🍻
Enable Coveralls to leave comments on PR’s
Tags: Github, Continuous Integration, Coding, Software Development, Programming

Problem

I noticed that Coveralls bot was not leaving comments on pull requests for my new repository.

I found this issue but it describes how to add the bot to private repos.

Solution

Going to my Coveralls repo settings, I noticed Leave Comments? was disabled:

Once I enabled Leave Comments? and saved changes:

Coveralls bot started adding comments to my GitHub PR’s:
How we created a cloud continuous integration service
Tags: Continuous Integration, Continuous Delivery, Cloud Services, Cloud Computing, Programming

When a company works on several projects simultaneously, it faces a number of difficulties. Using cloud CI is expensive, and the way you are charged is often unreasonable. The server is used only for a few hours, but you pay for it as if you were using it all day long. Creating your own data-center is even more expensive than renting the appropriate equipment. Each project has to be configured, test servers need to be created and monitored, and a lot of professionals need to be allocated to those tasks. Using cloud CI is not always fast, because you have to wait in the queue to run tests.

At first, we had been using Amazon EC2 as a cloud service, but we needed servers physically located on the same host, and we decided to use Rackspace. We also used RabbitMQ, as it has the ability to build branchy queue topologies and exchange points, as well as configure routing between them.

What is more, we have integrated a number of preinstalled packages like Xvfb, Postgresql, Mysql, MongoDB, Redis, Elasticsearch, PhantomJS, and SphinxSearch, which makes Vexor incredibly convenient to use. The users of Vexor can perform tests in such languages as Ruby, Clojure, Scala, Python, Haskell, React, Elixir, Solidity, Node.js, Go, Rust, and the work of developers is significantly simplified and speed up. The original code of the project can be stored at GitHub, Bitbucket, or at GitLab.

Vexor uses Docker, as it is stable and delivers a minimum number of problems. Tests in Vexor are launched in a container based on Ubuntu, where all popular services and necessary libraries are preinstalled. Moreover, Vexor can discover what technologies you need automatically. Hence, for unrecognized cases, the app asks the users to make a configuration file for the project. Vexor uses many servers and such tools as Ansible, Packer, and Vagrant.
IfCI — Introduction (part 1). Inside fleetster CI — Introduction
Tags: Continuous Integration, Gitlab Ci, Gitlab, Fleet Management Software, Pipeline

This post will be the first of a (hopefully) long series about technical challenges we’ve faced implementing our C ontinuous I ntegration workflow.

The technical team at fleetster is striving every day to make its life easier.

We are a small company of 17 employees with a disproportionate technical team (12 members are in the technical department). We build a global web service for mobility providing modules for corporate carsharing, fleet management, logistics, and others. The system operates with or without hardware integration (data kits, vehicle control devices and/or electronic key boxes). This creates a challenging ecosystem complex to navigate on a technical level. The core technologies are node, react, redux and ember.

Backend / frontend / mobile developers, Q uality A ssurance, designers, and DevOps are all involved in our workflow:
3 Git Workflows to Showcase Unfinished Work
By: Remco Rakers
Tags: Continuous Integration, Software Development, Programming, Software Engineering, Git

The Solo Workflow

Working by yourself on a software product makes things easy. You have a good overview of your work, you can pick up user stories one by one, and when the time comes to have your work reviewed, you can release the changes to a central development environment. Ideally, you make use of a CI/CD setup that helps you build, test, and release a new version without manual intervention.

Git workflow that implements a serial deployment and review process. Photo by the author.

After you have deployed the new version, you can verify the functionality and ask for feedback. In the meantime, you can start working on another user story, from a new feature branch, while the review is pending.

When the review is done and there’s feedback to resolve, you can implement the requested changes, initiate a new release from your feature branch, and deploy a new version to the development environment. After a final verification by you and the reviewer indicating that everything is working fine, you can finalize the changes by merging the feature branch to your main branch.

But what happens when feedback on the first feature that you implemented hasn’t come and the next user story you picked up is ready to be tested and shown to the product owner and stakeholders? You can, of course, deploy from your new feature branch, but that will overwrite the changes that are currently deployed on the central development environment from the other branch.

One solution is to create separate environments for every individual change. This is what the Multi-Environment Review Workflow is about, and I will describe it in a moment. But there’s also a simpler solution called the Integration Branch Workflow.
How to Deploy Your Application to Digital Ocean Using GitHub Actions And Save up on CI/CD Services Costs
Tags: Continuous Integration, Servers, Github Actions, DevOps, Digitalocean

STEP 1

CREATE A NEW REPOSITORY THAT WILL HOST YOUR APPLICATION ON GIT HUB

In this step,we will head over to our GitHub account and create a new repository that will host our desired application. Follow this link to see steps on how to create a repository on GitHub: https://docs.github.com/en/free-pro-team@latest/github/getting-started-with-github/create-a-repo

To clone the repository below and skip step 1,2 and 5. Click on this link : https://github.com/Mulubwa17/ci-cd-to-digitalocean-with-github-actions

In this case ,I created one and named it as shown below :
GitHub Actions For the Win
By: David Mezzetti
Tags: Github, Unit Testing, Continuous Integration, Software Development, Programming

GitHub Actions For the Win

Photo by Wilhelm Gunkel on Unsplash

Do you use GitHub for version control? Do you like to test your code? The answer to question #1 for many is yes and everyone should answer yes to question #2. Great, now that we’re on the same page, let’s talk about GitHub Actions.

GitHub Actions is a framework for automating workflows. Workflows are created in YAML and automatically run right on GitHub repositories. The link below gives an excellent overview of GitHub Actions.

The documentation above does a great job introducing GitHub Actions along with workflow file syntax. This article introduces a couple basic workflows that are used to add continuous integration on GitHub projects.
Running Postman collections in Jenkins as a part of CI/CD
By: Aytac Tas
Tags: Jenkins, Postman, Docker, Continuous Integration

In this article, I would like to demonstrate how Postman can be used as an automation framework in CI/CD pipelines running on a Jenkins.

We are going to use containerized versions of Jenkins and Newman. Newman is the CLI version of Postman. We’re gonna have to apply “Docker in Docker” approach to run Newman container inside of Jenkins container.

The volume mechanism on Docker will persist data and we are going to use that for two purposes. First, to be able to run the docker container in another docker container (docker.sock will do that job) and second, to be able to send postman collections into Docker container.

So, we need to define the path on the host machine so that container can retrieve the data from there (Of course we need to put the postman collection we want to run into that path). After the colon, we need to add the container path which is the part we want to target on the container.

-v ${host_machine_path}:${container_path}

Step 1: First of all, we install a docker image for Jenkins from dockerhub. We should customize our Jenkins image so that it can mount the host machines’s docker socket to Jenkins container. We also should install docker ce into our container. In order to do that, we are going to build an image by extending official Jenkins image as below:

FROM jenkins/jenkins:lts USER root

RUN curl -fsSL

RUN add-apt-repository \

"deb [arch=amd64]

$(lsb_release -cs) \

stable"

RUN apt-get update && apt-get install docker-ce=17.12.1~ce-0~debian -y

RUN usermod -aG docker jenkins RUN apt-get update -qq && apt-get install -qqy apt-transport-https ca-certificates curl gnupg2 software-properties-commonRUN curl -fsSL https://download.docker.com/linux/debian/gpg | apt-key add -RUN add-apt-repository \"deb [arch=amd64] https://download.docker.com/linux/debian $(lsb_release -cs) \stable"RUN apt-get update && apt-get install docker-ce=17.12.1~ce-0~debian -yRUN usermod -aG docker jenkins

Only thing you need to do, is creating a Dockerfile, then run the following command on the same path to build an image:

docker build . -t my_customized_jenkins:latest

Step 2: Run the image to create a container:

docker run -p 8080:8080 -p 50000:50000 -v jenkins_home:/var/jenkins_home -v /var/run/docker.sock:/var/run/docker.sock my_customized_jenkins:latest

Once the installation is finished and set up is done, we’re gonna have a Jenkins server on our local, up and running.

Step 3: As a final step, we create a job for running Postman collections within a container by navigating to the “New Item” section. The only thing we need to do is to add the following command on the “Execute Shell” field.

docker run -v path_on_host:/etc/newman -t postman/newman run "test_postman_collection.json"

Here we are! We can run Postman collections with Jenkins containers as a part of CI/CD.
CI/CD com GitHub Actions + Fastlane
By: Aryella Lacerda
Tags: Continuous Integration, Continuous Delivery, Continuous Deployment, Github Actions, Fastlane

Learn more. Medium is an open platform where 170 million readers come to find insightful and dynamic thinking. Here, expert and undiscovered voices alike dive into the heart of any topic and bring new ideas to the surface. Learn more

Make Medium yours. Follow the writers, publications, and topics that matter to you, and you’ll see them on your homepage and in your inbox. Explore
มาลง Gitlab-runner ไว้ใช้เองกัน
By: Taeng Trirong Pholphimai
Tags: Gitlab Ci, Continuous Integration, Continuous Deployment, Gitlab Runner, Gitlab

Learn more. Medium is an open platform where 170 million readers come to find insightful and dynamic thinking. Here, expert and undiscovered voices alike dive into the heart of any topic and bring new ideas to the surface. Learn more

Make Medium yours. Follow the writers, publications, and topics that matter to you, and you’ll see them on your homepage and in your inbox. Explore
CI, CD and DevOps Introduction
By: Kathiriya Niket
Tags: Continuous Integration, Continuous Delivery, Deployment Automation, DevOps, Integration Testing

Operations Team -> Execute Script for Test Env-> Automated preparation, deploy and tests -> Execute Script for Production Env -> Automated Preparation, deploy and tests.

NOTE:- Having a developer with operations knowledge does not mean DevOps. DevOps is this entire process of making everything automated in the above-mentioned manner.
Chaos Engineering Automation with Drone and Gremlin
By: Tammy Bryant Butow
Tags: Chaos Engineering, Continous Deployment, Cicd, Continuous Integration, Ci Cd Pipeline

In this tutorial, we will demonstrate how to use Drone to create an automated chaos gauntlet for our services and applications. This will be done using Drone to inject a controlled amount of failure with Gremlin while building new services. We’ll then also share how to use Gremlin to automatically run a Chaos Guantlet when deploying new services to Staging and Production environments.

Gremlin can be easily integrated with Drone using the Gremlin API.

Prerequisites

Before you begin this tutorial, you’ll need the following:

Drone installation

A Gremlin account (sign up here)

Step 1 —Choose a repository

In this step, you’ll choose a repository. For example, I am choosing to build the Drone_Memcache repository:

We will be using the drone_memcache repository as an example

Step 2— Add Gremlin secrets to Drone

In this step, you’ll need to add your Gremlin secrets to Drone. This includes your Gremlin API Key, Gremlin Team ID, and Gremlin Secret. These are secrets that are required to run attacks in an automated manner. Select your repository, select settings, then add your secrets:

Step 3 — Create a .drone.yml file in your repository

Create a file called .drone.yml in your repository. This file should be used to build your services and call the Gremlin API to run your first set of Chaos Engineering attacks using Gremlin. Once you save this drone file you’ll be able to kick off the build of the drone_memcache repository and your automated Chaos Engineering attacks. We recommend using the Gremlin in-app API examples provided for you to craft your curl commands.

Drone will automatically spin up a Docker container (or Kubernetes pod) to build your service and run automated Chaos Engineering attacks with Gremlin.

Congratulations, you have now completed your first set of automated Chaos Engineering attacks. We also recommend you run a set of Chaos Engineering attacks after deploying your code to Staging and Production.

Conclusion

This tutorial walked you through how to create a Chaos Pipeline for Staging that runs an automated Chaos Gauntlet. This makes use of the Gremlin API, Drone, and Concord. We used Drone to create these CI stages, but you can also use Gremlin with other tools such as Jenkins, AWS Pipelines and Spinnaker.