Yes, the macOS M1 + macOS Intel build servers support Android builds. We automatically setup the servers to support multiple versions of Android with the Android SDK as well as provide Xcode versions based on your needs. It is possible to get multiple versions of Xcode as well just ask.

Customers that use the macOS build server for both iOs and Android can build in parallel avoiding any unnecessary wasted time or bottlenecks.

No it definitely does not. We create some amazing developer experiences with Jenkins CI and using declaratice pipelines and shared libraries can have very extensible pipelines and workflows that allow developers to get fast feedback and be very happy.

Software development involves multiple software engineers who program daily new source code for a specific software project. These developers commit source code to a source code repository. All developers use the same source code repositories, and the source code repository ensures they all have the same source code version. In addition, source code managers use branching to trace generational changes in source code and make merging changes easier. New releases, features and bug fixes are all created on branches and merged when they are ready to be released.

To optimise source code building, testing, and refinement, teams use a CICD server like Jenkins. The CICD server integrates with the source code manager to pull down the latest source code. Then, the CICD Server builds, tests, and packages this source code version and sends a notification to the development team to verify the package.

In our opinion, CICD is one of the most significant contributors to highly functional software development teams and a big contributor to their productivity.

Software development practices have evolved significantly in the past decade. Today most software development teams need to build, test and package code on all their branches, and they need to be able to build, test and validate pull requests before merging. As a result, the load on the CICD server has increased significantly. Fortunately, Jenkins manages concurrency very well, and today, our Large Jenkins Controller has 48X concurrency. It can handle running more than 48 Jenkins queued jobs at a time.

Concurrency in Jenkins requires planning and engineering consideration and is not automatically available out-of-the-box. Our Managed Jenkins Service provides high levels of performance out-of-the-box, but the standard Jenkins Software requires customisation to meet the requirements of modern software development teams.

To improve concurrency levels and the efficiency of your Jenkins Controller, we recommend avoiding combining multiple software development teams on a single CICD server. The main reason is to enable each team to utilise each CICD server fully. When multiple teams share a server, there can be contention and bottlenecks.

Without concurrency building, testing and deployment would take incrementally more time to complete. As a result, concurrency and parallelism are valuable commodities. Jenkins provides the lowest price point for concurrency and parallelism, enabling your teams to build, test and deploy software faster than any other CICD solution.

Our Jenkins Service leverages Jenkins in a Controller/Agent architecture pattern. In this mode, Jenkins orchestrates workloads, manages incoming webhooks, and delegates work to multiple ephemeral agents, which are dynamically provisioned on a infrastructure-as-a-service provider or configured on a Kubernetes cluster. Jenkins then computes and reports the result to the user. Jenkins provides realtime console log of the agent logs and provides multiple ways to debug errors and interact with the agent.

We recommended a Controller/Agent architecture for production workloads. Furthermore, the Controller/Agent architecture is the most secure way to run Jenkins.

Running a Jenkins server is complex and does come with a steep learning curve. We recommend any organisation using Jenkins to review the available resources online for security best practices. There are two requirements from a security perspective; The Jenkins Server should run on a well-secured Linux server amd the Jenkins service should run as an unprivileged ‘Jenkins’ user, and overall system privilege should be restricted. We also advise; The Jenkins Server should be hosted on a TLS endpoint only. Use IP Whitelisting and a SAML based user management plugin. For long term stability perform regular updates and manage plugins actively. Shameless pitch- If this isn’t something you want to undertake, our Services like the Managed Jenkins Service and Jenkins Support can accelerate your adoption. In addition, Servana is an Official Cloudbees Partner for EMEA, enabling you to access more services from the Cloudbees Inc.