DEV Community: Imanol Valiente

Improve Your Remote Work

Imanol Valiente — Fri, 08 Nov 2019 00:44:48 +0000

For the last two years, I‘ve been working from home; actually, I have the freedom to choose from where I work, but it’s funny that I always end up working from home.

It is probably one of the most grateful experiences I had in my career. I have proven I am trustworthy and reliable while independent, I have learned to be more organized, and I can focus on my career while keeping close to my known beings.

Life is short, spend it with people you love.

Remote working indeed gives you a lot of freedom and the chance to choose how and where you live your life, but it also involves responsibility and discipline. According to the type of schedule your company demands, fixed or not, you need to plan and comply with your schedule as if you went, every morning, to the office.

Having a routine that you can stick and follow helps in developing the discipline, but it’s easier to follow a group of people than going on your own. So you have to learn to be confident with the decisions you take and stick to a routine based on those productivity techniques that make you a better professional.

I will list a few tips from my experience to make the best of your remote work.

Adjust your habits to the new experience

A good thing about not working in an office is that you can choose where to work from and how your workspace looks.

The first thing you should take care of if you decide to always work from your home is the routine you are going to follow, make a generic plan of a working morning that is realistic, and compromise to achieve it every day. It’s quite important to be careful with loneliness and know how to deal with it.

A piece of advice, focus when you are working and once you finish, get off your computer, try to spend time with your friends or family, go to the gym and do some exercise, There’s nothing better than releasing endorphins after a hard day at work.

I always try to go out throughout the week and spend most of the weekends relaxing at home, focusing on my learning and feeding my entrepreneurship spirit.

Every two months or so, I try to plan a trip and visit a new country to heal a bit my mind from the repetitive cycle of work, eat and sleep.

It’s also an excellent habit to eventually meet with your teammates and spend a few days working with each other face to face doing some team building and sharing experiences. You will find the human side of that voice behind the screen that feeds you with tasks, questions, and GIFs.

Improve your communication skills

It looks like a contradiction, but working on a distributed team enhanced my communication skills in a way that I never thought when I started that I was so bad at communicating my ideas.

I don’t usually share video, just voice. But after a few calls with teammates and other people involved in the project, I realized that face to face communication is less productive than calling through phone or any VoIP software.

When you are standing in a room having a meeting, discussing ideas or sharing knowledge, it’s a common thing to have people asking questions, speaking with each other or just interrupting. If you have to explain or transmit a complex idea, you can help your words with gestures and physical interactions. Sometimes when we tell stuff, we expect a confirmation gesture from our listeners, like a nod.

When you are behind a microphone, with a call going on and you have to explain a complex topic, even if you are sending video, due to the latency of the network, it’s not easy to coordinate your explanation with gestures or physical interactions. It just doesn’t feel the same as doing it in place.

Also, if you add those that interrupt the meeting with questions that aren’t questions because they realize later that what was going to be asked, it’s already answered, the whole session can become chaos.

For example, when you are on a VoIP call explaining something and someone starts to speak at the same time, both voices mix up and people don’t understand you anymore. That kind of interruptions takes a few minutes to be recovered as both voices are heard at the same time and both parties have to decide who’s turn is.

So for anyone starting with voice calls I suggest:

Mute your microphone always unless you have something to say.
Don’t interrupt with a question that you are not sure you are going to end asking.
Pay attention; most doubts arise for not following the speaker.
Always be concrete and concise.
Buy quality equipment and always use headphones, software-based echo filters do not work and it’s quite annoying to be interrupted with your voice when you are explaining a complex topic. *You already know that latency is present on every internet communication. Be flexible with human errors that happen on-screen shared sessions and wait a bit before interrupting for a mistake that probably it’s already fixed.

Improving your communication skills will speed up your meetings, as it’s proven that long meetings are the bottleneck of most of the employee’s productivity; it will help you be more efficient.

Be productive and measure it

When I started with the remote experience, the first month or so, I used to think that I wasn’t working enough. Not having a teammate near me knowing that I was working made me feel, when I spent more than a day or so to finish a task, that I wasn’t working enough.

This is a matter of trust and if you are remote working, you have to trust your teammates, so if you work hard, don’t bother with that feeling like I did, probably you’re working more than enough.

The best thing you can do is measure it, if you work on a distributed team you have fewer eyes on you, which means that you can try different ways of working to improve your productivity. Don’t miss the opportunity, measure and compare it, there’s is a business behind productivity techniques, people get paid for coaching workers that want to boost their productiveness and I’ve seen tons of books on this topic already.

For sure, you make use of a task tracker, so take a batch of your tasks, organize them, plan them, follow a known productivity technique and measure the result. Try changing something on your method for the next batch of tasks and compare it with the previous results. This way, you will achieve a continuous improvement that adapts to your way of working better than sticking to the already existing techniques.

I’ve seen and been suggested a ton of techniques to improve my productivity, I am seriously into these techniques and actually, I spend time trying to understand them enough to see if they adapt to the tasks and kind of work I perform. For example, when I am into tasks that require investigation and document reading, I like the way the Pomodoro technique splits the work into intervals of 25 minutes, this way I don’t get overwhelmed with all the new stuff, but if I am into a more repetitive task where all I have to do is throw lines of code to describe the resources of a cloud environment in Terraform I tend to ignore this technique, take my headphones, put some music on and get the things done.

I’ve found a few techniques that work and make me stay more focused, increase my productivity and my desire to get things done.

At the end of every day, I try to plan what I need to do for the next day, this is not my primary source of tasks, I work with an issue tracker known as Jira where my team plans all the tasks that must be achieved in a period of time (usually 2 or 3 weeks). So I take the main tasks I am working on and split them into smaller tasks, the goal is to plan shortly, so I keep myself motivated through the days by finishing earlier smaller chunks of the main tasks.

I try to keep track of everything I do and plan what I have to do for the day to come. Still, sometimes there are a few tasks that appear throughout the day, those are tasks that I try to finish as soon as they arise, but they’re not always short enough to finish them without losing context on the main task I was working. I once heard about a simple rule, and that’s what I follow.

If it takes less than 5 minutes do it now.

My day to day involves a lot of tasks, to keep track of what I’ve to do I always write everything in a notebook or a To-Do list. That’s a habit I started when I realized my mind could not remember all the things I had to do.

There’re a few conclusions I got from working from home; an office has too many distractions for me, a job should not be the main reason for an employee to move to another city and if all the companies promoted remote working, the population between towns and villages would be more balanced. I think we can fight climate change as well by not taking the car every morning to move to the office.

Jenkins Configuration As Code

Imanol Valiente — Mon, 30 Sep 2019 00:38:03 +0000

It has been some time since I started working with Jenkins. One of my daily duties with this tool goes from, supervise the execution of legacy Jobs, to maintain and enhance declarative multibranch pipelines, always trying to achieve continuous integration and continuous delivery practices to promote packaged software through many environments until it gets the client's hands.

Reaching out such a level of automation involves time, teams & processes. From my experience, It's a task that requires a lot of time and effort, everyone involved in the Software Development & Delivery process has to take hands on this new way of thinking & working, and adapt to it.

After spreading a bit my thoughts on the DevOps culture, I would like to focus once again on the Jenkins topic. I spend most of my time between environments, and for each environment I work on an entirely different Jenkins, actually I test new features from fancy plugins that improve and clarifies the Software Delivery process on a Dev environment and once I verify the new feature works well I spend more time promoting it to the rest of the environments, this sounds like a repetitive task, actually I tend to avoid this kind of tasks, for over the years I pursue the adoption of EaC, Everything as Code, but for some reason, I had no chance to apply it yet on the Jenkins installation scope.

So that's the main topic, I found a weakness on my daily duty, I am trying to achieve a solution, and I'll write about it.

The Goal.

The desired state I would like to reach is to be able to build a Jenkins instance where all of its configuration and Job definitions goes in declarative files, this way we have immutable Jenkins instances that deploy on any environment, whenever you add a plugin, job or modify a configuration it gets stored and versioned on Git, this way, no unknown configuration is able to break the desired state of the instances anymore and anyone can deploy the exact state on their localhost, for testing purposes for example.

How to?

I have decided to structure the project in two repositories.

There's an initial project to set up the configuration at Jenkins instance level. On a file, we add the plugins to install and lock their versions, one of the plugins Jenkins Configuration as Code lets us predefine the global configuration of Jenkins and the rest of the plugins without interacting with the Jenkins UI, finally a Dockerfile is used to build a Docker image that includes all the initialization files.

A second project is used to interact with the Jenkins DSL plugin; the goal is to store the jobs, folders, and views as code on groovy files, so only what we have defined on our Git repository applies to the Jenkins instance.

I have decided to structure the project in two repositories.

Docker.

A widely known implementation of the Container software abstraction is used to pack, gather dependencies, and automate the deployment. We are going to build the Jenkins Instance using a Dockerfile.

FROM jenkins/jenkins:lts


COPY init-scripts /usr/share/jenkins/ref/init.groovy.d

ADD plugins.txt /usr/share/jenkins/ref/
ADD jenkins.yaml /usr/share/jenkins/ref/

RUN /usr/local/bin/install-plugins.sh < /usr/share/jenkins/ref/plugins.txt

ENV CASC_JENKINS_CONFIG /usr/share/jenkins/ref/

VOLUME /var/jenkins_home

The following shell script can be a useful resource to launch the build phase.

#!/usr/bin/env bash

docker build -t jenkins_as_code:0.1.0 .

There are two phases, the one that builds the container image and the phase that runs it.

Build phase.

Plugins Installation.

To automate the installation of the desired plugins, we are going to make use of an existing shell script included in Jenkins. The script its located at /usr/local/bin/, inside the container, with the following name install-plugins.sh, to install the plugins save them inside a file and call the script with the file as a parameter.

workflow-aggregator:2.6
configuration-as-code:1.30
configuration-as-code-support:1.18
credentials:2.3.0
blueocean:1.19.0
job-dsl:1.74

Now we can store in code the plugins that need to be installed and lock their versions.

JCaC Jenkins Plugin.

Working on Jenkins involves many plugin installations, for each plugin a specific configuration must be set up. All these configuration changes add up through time; a Jenkins instance tends to evolve based on the needs of the software delivery process.

The GUI is used to configure Jenkins; the thing is that there is no place to centralize and store what configurations are applied other than browsing it through the Web.

Most of the people have been solving this issue using groovy initialization scripts. It works, but as it involves some coding, its not as friendly and readable as desired.

The good news is the existence of a plugin that lets you define the global and plugin configurations through a YAML file. It's great because it handles the configuration changes and we can deploy an initial Jenkins install with all the configurations already applied.

So we can progress on the primary goal, the deployment of immutable Jenkins instances defined by versioned configuration files.

This plugin even lets you define a seed job, its a job that fetches DSL files and applies the changes creating other Jobs, views, and many more features.

In our case the following jenkins.yaml file is used to provide the configuration. The seed job fetches another project from Github that contains a few DSL based objects to create resources.

---
jenkins:
  systemMessage: "Jenkins As Code Concept."
  views:
    - myView:
        name: "Jobs Config as Code"
security:
  globalJobDslSecurityConfiguration:
    useScriptSecurity: false
jobs:
  - script: >
      freeStyleJob("Jobs Generator") {
        scm {
            github('imanol-dev/jenkins_as_code_jobs', 'master')
        }
        steps {
            dsl {
              external('*.groovy')
            }
        }
      }

A great thing about this plugin is that you can modify the YAML file and reload the new configuration, applying all the changes without the need to recreate the Jenkins instance.

Runtime phase.

Default User.

While working on this, I faced an issue trying to automate the creation of a default administrator user through a configuration file.

To solve it, I did some research and found a repository that makes use of Groovy initialization scripts; the script goes inside the container in the /usr/share/jenkins/ref/init.groovy.d directory.

This way, to create the user, we only have to fill the following environment variables

ADMIN_USERNAME=
ADMIN_PASSWORD=

Skip the Wizard.

Every time you deploy a new Jenkins instance, the first time you log in, you get prompted with a Configuration Wizard that helps you set up a few initial parameters and install some suggested plugins.

For newcomers, this can be kind of helpful, but we are trying to achieve automation that deploys what it's written in the configuration files, so we don't need this feature.

The way to avoid it is to run the container with the following environment variable.

JAVA_OPTS="-Djenkins.install.runSetupWizard=false"

Get It Running.

I work on a Linux based OS; it makes it easier for me to get things done, if you're not already on a Unix based OS I suggest you think about the change.

To get this working, you need Bash and Docker. Once you satisfy these requirements, you can clone the project.

.
├── init-scripts
│   └── admin-user.groovy
├── config
│   └── runtime.env
├── Dockerfile
├── jenkins.yaml
├── plugins.txt
├── build
└── run

The first step is building the Docker image from the current directory. There's a bash script to do this named build. It's a basic docker build command to generate the jenkins_as_code image in your local registry.

Once the image builds, it is time to get it running. There's another script run that runs the built image; it shares a volume to store the data Jenkins generates on the /var/jenkins_home directory (It's a must to create the jenkins_home directory before running the container), exposes the 8080 port and loads the config/runtime.env file as an environment file.

The Jenkins instance can be accessed through a web browser on the following localhost:8080 URL, sign in using the credentials initially set on the config/runtime.env file.

Once inside, there's a seed job to generate, through the DSL plugin, the rest of the desired jobs.

Job DSL Plugin. Jobs definition.

I have found a few ways to create Jenkins jobs; you can create them manually through the web interface, define them on XML files using the Jenkins CLI to import them, and make use of the DSL plugin.

The DSL plugin lets you define jobs on a declarative form, more human-readable.

I have defined a few jobs on a separate repository, using the seed job, I reference this repository, so after executing it, all the new jobs appear automatically. The seed job can be triggered off a git change, so if you delete or modify a job through code, this gets updated on the Jenkins instance without manual execution.

If you have the Jenkins instance running, roll the seed job to create the new Jenkins objects.

What about Ansible?

I did some research about this matter solved with Ansible, and I've found a few roles that let you install Jenkins in remote machines through Ansible Roles. There's a role that caught my attention that lets you tune up the configurations, setting up the variables associated to the role, this approach lets you choose between Containerized or VM deployments and define as code all your Jenkins Jobs in an XML format.

From my point of view this role its a great option but I wrote this post to easily store all your Jenkins Configurations and Job definitions as code in Docker containers, I am planning to evolve this first approach to end deploying a Jenkins cluster in Kubernetes using Helm so, from my point of view, Ansible does not fit for what I initially planned.

Conclusions

There are plenty of better approaches for the multi-environment deployment matter. A single Jenkins across all the environments could do the job, but sometimes it's not only about the best technical solution.

In my case, sometimes, I have to adapt to entirely isolated environments, with independent data centers and different network settings for the same project. A few years already in the business world have taught me that there's probably something more significant than my ideas already running and I have to adapt to it.

I enjoyed this research; I wanted to find a way to automate a few repetitive and manual tasks so I could deploy multiple Jenkins instances with the same configurations but with different Jobs.

Thanks for reading and if in some manner, this is helpful for you, do not hesitate writing me.