Automating Mobile App Development with Jenkins, Manuais, Projetos, Pesquisas de Sistemas de Informação

Baixe Automating Mobile App Development with Jenkins e outras Manuais, Projetos, Pesquisas em PDF para Sistemas de Informação, somente na Docsity!

• Forward: Why We Use Jenkins at Bugfender Table of Contents
• What is Jenkins and Why Should You Be Using it? What is Continuous Integration?
  • How Does Continuous Integration Differ from Continuous Delivery? How Does CI/CD Benefit a Devops Team?
• Intro to Jenkins Pros vs. Cons of Jenkins
• How to Install Jenkins in Ubuntu Selecting the Right Machine
  • Choosing an Operating System How to Install Jenkins
  • Recommended Detour: Add SSL to Protect Your Jenkins Installation
• How to Add your First Android Job to Jenkins Configuring Android App Builds in Jenkins
  • Accelerate Gradle (optional) Running Unit Tests
  • Running Integration Tests Suggestions for Next Steps
• How to Add Your First iOS Job to Jenkins How to Add a Mac Node for iOS Builds
  • Configuring iOS Jobs Adding Tests
• Closing Words Keys to Sustainability Maintaining Jenkins
  • Tips for Getting Started Today

################# #################

Jenkins makes sure our code compiles, so we save hundreds of hours of manpower because we don’t have to work through the tiny issues in compilation and shipping to a production-ready state. Every commit that is green is deployable to production. Boom, we’re done.

At its core, CI/CD is all about letting machines do what they do best

so humans can do what brings the most value to your company.

Of course, one of the main obstacles is belief in the value of CD/CI at every company level. As we will explain in the first chapter of in this ebook, there are complications to maintaining a CI/CD environment, and many developers find themselves trying to convince upper management why it’s worth it.

Fortunately, the hub of enterprise for Jenkins and DevOps, CloudBees, has put a number on the savings that businesses can expect from integrating continuous delivery in their devops teams. CI/CD is all about saving your company money: A CloudBees assessment of more than 100 enterprises revealed that continuous delivery enables an average efficiency gain of 66 hours per developer per year. For a 100-person team, this efficiency equates to 6,600 more hours to invest in innovation; an estimated annual value of $350,000 (^1).

Currently, though it seems CI/CD is a popular talking point, many teams haven’t made the leap yet or neglect the upkeep needed to keep their testing environment operative.

We created this ebook to help your company fast-track the

implementation of Jenkins, so you can start saving money + start

preventing a common developer headache.

################# #################

What is Jenkins and Why Should You Be Using

It?

A common problem for many devops teams is a fragmented

workflow.

Inefficiency can be infuriating.

You know how it goes: individuals on the team tend to work independently. Coding solo, engineers regularly create large segments of code outside of version control. Once a developer is “done,” they add their work into the basecode. Then another team manually runs tests to verify the build.

For years, many teams have found this division of labor annoying and problematic.

################# #################

There are various levels of testing automation that you can implement: The most basic test is whether or not the code actually compiles. Code can also be “linted” or checked for style. Your team can write more complex tests to cover other bases as well, including unit, integration, stress, regression testing, etc.

How Does Continuous Integration Differ from Continuous Delivery?

A CI service compiles and tests a full application (possibly by running the application in an emulator). Continuous delivery also pushes this compiled application to a repository, for example, for alpha testers to use and provide early feedback.

CD builds are automatically deployed through to the production environment and can also be used for broader beta testing.

################# #################

CD is aimed at lean-logistics: automating the process from adding new code through to acceptance testing. CD automates all the steps so that your build is ready to be deployed.

➔ (^) Continuous delivery: Besides building the application and running tests on it, the application is also “delivered,” which often means putting it on a server for someone to perform manual tests on it, or sent by email to a test group of users (eg. a mobile app sent by email). ➔ (^) For production builds, delivery means deploying the application for the end users.

This allows for faster, smaller deployments of your product which reduce deployment risk. Regular, smaller, leaner deliveries are less risky that huge ones that only occur once or twice a year.

How Does CI/CD Benefit a Devops Team?

A lot of people talk about CI because it is a best practice to have all code verified automatically on every commit, regularly run tests, and continuously deploy–for the reasons mentioned above. The process checks that the contributions from each developer work well together. Detecting these issues early makes it easier and faster to fix the bugs.

As you can probably guess, implementing CI/CD will cause a cultural shift in your team. You will have to become more agile and integrated.

As we mentioned in our intro, CI was created to allow your team to stop wasting human time trying to manually resolve conflicting segments of new code, trigger builds, or run tests.

################# #################

Intro to Jenkins

Jenkins is an open source implementation of a CI server written in Java that can be used as a self-hosted option automating the build cycle for any project. It works with any programming language and for multiple platforms including Windows, Linux and macOS. According to the Jenkins website:

Jenkins, originally founded in 2006 as “Hudson”, is one of the leading automation servers available. Using an extensible, plugin-based architecture developers have created hundreds of plugins to adapt Jenkins to a multitude of build, test, and deployment automation workloads. In 2015, Jenkins surpassed 100,000 known installations making it the most widely deployed automation server.

One of the main benefits of Jenkins is that it is a well-known tool with lots of community support, there are many plugins available (including well-known names like Slack, GitHub, Docker, Build Pipeline + more), and the project is well-maintained by a large community of developers.

There are a lot of conversations going on about CI/CD and the Jenkins project. But even as late as 2017, a surprising number teams don’t utilize or

################# #################

maintain their systems because running a CI environment is costly, either in time or money, often both.

So why even bother with them? Let’s look at that question.

Pros vs. Cons of Jenkins

Jenkins is an old tool with an unfriendly user interface.* (*The good news is that the Jenkins project just released Blue Ocean, a continuous delivery software aimed at significantly improving the UI. True to form, it is 100% open source.)

As your team considers options for continuous integration, it is helpful to note that Jenkins must be run on a server (cost), so it often needs the attention of someone with system administration skills (time). You can’t just set it up and then expect it to run itself–the system requires frequent updates and maintenance.

Yet, Jenkins is open source and one of the best and most widely used free tools out there for implementing CI/CD for your devops team.

The main barrier to entry for most teams is the initial setup, procrastination, or failed previous attempts to set it up.

People tend to know it’s a best practice, but many teams neglect it for more urgent coding work. Perhaps someone on your team tried to implement Jenkins at some point, but did not successfully maintain it. Maybe the wasted effort gave your boss a bad impression about it.

As it is, the reasons people do not implement a CI server are usually very practical.

################# #################

Still, the brief sacrifice of time translates into long-term benefits for the whole company ($$$). With Jenkins, your code is easier to maintain and fewer bugs sneak into production. Your team becomes more integrated. Builds take less time. Your business can ship faster and keep up with the changing needs of your customers.

All of this will require a mindset shift:

CI is not an expense but an investment. And the ROI for implementation can be counted in time saved, errors avoided, and higher quality products delivered more easily to your clients.

################# #################

How to Install Jenkins in Ubuntu

If you’re getting started with Jenkins, there are many things to

consider before you hit download.

You have to choose where to run Jenkins: on hardware that you maintain yourself or through a hosting service. You should work with your team to decide on the best option for your needs.

As a fully remote lifestyle business, we chose to use Amazon Web Services on a t2.nano machine type with Ubuntu 16.04, but this configuration can be adapted depending on the use case.

Selecting the Right Machine

Make sure you choose a machine with at least 1GB of RAM. If you don’t have enough internal memory, Jenkins won’t run. For decent performance, 2 to 4GB is ideal.

################# #################

Step 2: Open Your Browser

In your browser, go to http://your-ci-server-name.com:8080. If your machine is running Jenkins, the window should display the setup wizard.

Step 3: Unlocking Jenkins

In order to ensure that you’re the real administrator of the machine, the password has been written to a specified log file. In a fresh terminal, type in sudo cat and then paste in the pathway provided on this page in order to get a temporary password. Then you can enter the password in the Administrator password field in your browser.

This step is a security measure in case your Jenkins download is publicly accessible from the internet or your company’s network. (For information about more security measures for Jenkins, see “Recommended detour: add SSL to protect your Jenkins installation” below.)

################# #################

Step 4: Customizing Jenkins Plugins

You can go ahead and click the Install the suggested plugins box. This will activate the download of a handful of useful plugins, including Git and some Pipeline plugins. You can always download other plugins as necessary to supplement these pre-selected options.

################# #################

Recommended Detour: Add SSL to Protect Your Jenkins Installation Since Jenkins has access to your application’s source code, we recommend you use encryption. The essence of your product–the code–is likely sensitive and should be kept private. If you are running Jenkins through the internet or on a local network shared with other people, it might be good to protect communications with SSL.

Since the launch of Let’s Encrypt, it’s fairly easy and completely free to get these certificates, so we highly recommend it. Don’t be lazy!

Step 1: If your server is behind a firewall, first make sure you are accepting inbound traffic on ports 80 and 443, and remove access to port 8080.

In order to get SSL working, you’ll first need a DNS name for your server. In this example, we are calling it your-ci-server-name.com. Make sure to edit the

################# #################

configuration files we will be listing here to match the domain name you choose.

Step 2: Then install nginx (sudo apt-get install nginx) and edit your /etc/ nginx/sites-enabled/default file to look like this: upstream server app_server 127.0.0.1:8080 { fail_timeout=0; } server listen { 80 default_server; listen server_name [::]:80 _; default_server; location alias ^~ /usr/share/nginx/html/.well-known/acme-challenge/; /.well-known/acme-challenge/ { } location / { }^ return^301 https://$host$request_uri; } Once it is installed, ask nginx to load your changes: service nginx reload

This will let the Let’s Encrypt validation service talk to your server and verify that you own it.

Step 3: Now you can install the Let’s Encrypt agent and make an SSL certificate for your server:

sudo apt-get install letsencrypt Letsencrypt

Follow the steps of the wizard and you will end up with your SSL certificates in a directory like /etc/letsencrypt/live/your-ci-server-name.com/.