A full mobile delivery automation setup in 5 minutes In this post we are going to explain how to make application deployments using Clarive EE both to the Google Play Store, and to the iOS store (Apple Store) thanks to the Clarive Plugins This process will not require any additional programming knowledge. Thanks to the interface offered by the rules designer we’ll be able to configure these deployments. For more information about Clarive and the components we use, see our Docs. Deploying to Google Play Store General features In the case of Android applications, the Gradle plugin is used to compile the application, and the Fastlane plugin to send it to the Play Store automatically. Configuration Beforehand, we need to ensure that there is already a first version of the application uploaded so that the deployment can be carried out automatically. We then create a Generic Server from the Resources → Server panel. On this server we have the application installed together with Gradle and Fastlane. Once we have configured the server, we need to go to the rules designer and create a new rule with the type Pipeline in the Admin panel. We then use the PRE phase to compile the application. To do this, we drag the operation Gradle compile: In the set up box that appears, we should select the server that was previously configured, and fill out the remaining fields in order for it to compile correctly. We then need to drag the operation Fastlane task to the RUN phase in order to configure the upload of the application to the Play Store: We then fill in the operation form with all the necessary data ready for the upload. We are now ready for the deployment to Play Store. Next we need to add the operations to deploy to Apple Store using the same Pipeline. Deploying to Apple Store General features This time we’ll use the Fastlane plugin to compile and send the application to Apple Store automatically. We need to ensure that Xcode is installed together with Fastlane. Configuration We now need to create a Generic Server, just like we did previously. On this server we have the application installed together with Fastlane and Xcode. We must also configure the access credentials for our Apple Store account in the Resource iOSCredentials, which we access from the Resources → iOS panel. In the same way as we did previously with Android, we’ll compile our application in the PRE phase, with theFastlane task operation. Within the configuration of the operation, we need to select the server, the credentials, and fill in the rest of the necessary fields. We then configure the delivery of the application to the Apple Store, using the same Fastlane task operation in the RUN phase. We need to select the ‘Upload App’ option, and fill in the fields. With this Pipeline we have now set up automatic publication both in the Play Store and the Apple Store. If you have any questions please don’t hesitate to contact us at Clarive Community. Get an early start and try Clarive now. Install your 30-day trial here.
What’s New in Clarive SE Release 7.0.9? We’re pleased to present our latest Clarive SE release 7.0.9. This release contains a number of fixes and improvements from 7.0.8. New settings menu The product team is constantly working on further improving the Clarive UI, with a special focus on user friendliness to new users. This has also been the case in this release. First of all, we improved the Config option in the Admin menu. We improved the interface and renamed it into Settings, see below: In this new design we divided general configuration into sections, allowing users to see all options more clearly and intuitively. Rulebook shell multiline Rulebooks are one of the most unique features in Clarive so we are further improving it to make them even more flexible and usable. This release adds multiline capability in the shellcommand, so users are now able to write rules like: do: - shell: | ls -lart echo hello > hi.txt cat hi.txt Or simpler: do: - | ls -lart echo hello > hi.txt cat hi.txt Change username and email in Preferences Prior to this new release, if a user wanted to change username or email address, the tool Administrator needed to be contacted as only this person could do it. We added in our latest release under user preferences two new fields allowing users to change their username and email: Move artifacts menu from Tools to Deploy Ease of use comes with predictability. We want to achieve this without losing the essential capabilities of the product.That’s why the product team has been reviewing menu consistency with the focus of making it more intuitive and clear where options are to be found in the lefthand side menu. As s result, we have removed the Tools option in left panel and added Artifacts in Deploy menu. Improvements and issues resolved in this release [ENH] – Improvements in rulebooks documentation [ENH] – Ext-to-React panel now supports ES6 [ENH] – New Dockerfile for supporting both adduser and useradd containers [ENH] – Custom antd components [ENH] – Rename clone URL button [ENH] – Admin user has group permissions on initial load [FIX] – Force Clarive migrations in default config file [FIX] – Admin user email is saved in cla setup [FIX] – Jail dump file op in rulebooks [FIX] – Wider revision column in revision fields [FIX] – “Ship a file remotely” op show confirm window before overwrite existing file [FIX] – Update number of rows in topic grid when topics are deleted [FIX] – Fix position of Gauge dash let Visit our documentation to learn more about the features of Clarive.
(R)Evolution in Delivery Automation paradigms (1/4) This post is the first in a series of 4 covering different types of automation methods. Organizations that want to deliver application, service and environment changes in a quick, consistent, and safe manner and with a high level of quality, invariably need a good and flexible automation system. Choosing the correct automation method from the start can make the transition to continuous or automated delivery a lot easier. Current tools for delivering applications in the DevOps and ARA space usually fit into one of these three automation paradigms: Process or script driven Model driven Rule driven In the past, and in many realms of automation systems, process/script-driven approaches have prevailed. More recently, especially since the inception of the cloud and software-defined infrastructure, model-driven automation has become increasingly popular. However, as I will explain in this blog series, both process and model-driven automation have serious drawbacks. These drawbacks tend to result in a considerable amount of rigid processes that are expensive in terms of maintenance and evolution, or simply very hard to introduce in the first place. In addition, delivery quality can be seriously impacted. This blog post is the first of 4 that will elaborate on each paradigm individually, discussing their approach, features, and drawbacks. Process or script-driven automation The first paradigm I want to discuss is script or process-driven automation. It is a method based on a clearly defined, start-to-end process flow that defines how change is delivered to destination environments, typically a series of procedural steps executed to deploy the entire application. But consider this: such an approach can become painful due to the trend that requires today’s developers to build scalable applications and apply a strategy based on hybrid clouds and platforms to attain flexibility, continuity at the lowest possible cost. With multiple platforms in mind, a process/script based solution means you need a unique process for each platform, cloud, application, and/or environment. Since scripts are unique to each combination of process, environment, and app, they are called tightly coupled. As a result, deployment processes may need to be rewritten several times throughout the lifecycle of the application — any time the application, middleware, or components change. Another weakness of the process-driven approach is that it does not offer the opportunity to align teams around the same toolset. In fact, it encourages individual teams to maintain their own catalogue of custom-built scripts, in their technologies of choice, and prevents the rest of the organization from benefiting from their investments. This is the worst possible way to implement DevOps practices and instate lean principles within application delivery as it nurtures silos and obstructs collaboration and sharing – while often making the delivery toolchain unnecessarily complex. Coding: an analogy Let’s make an analogy within software development itself to make this clearer. Process or script driven deployment is in a way analogous to coding using a particular programming language or IDE. Since each development team writes code in a different language, it does not offer the opportunity to align teams around the same code set or make it easy to share code across teams. Although in recent times programming languages have become much more platform neutral, recall that in the old days, languages were very bound to platforms and machines as well as they included specific coding instruction sets closely supporting the platform or machine they supported. This also resulted in issues with sharing or migration of code across platforms. This is very similar to the issues I see with scripts/processes for deployment. So, in summary, a process is defined as a series of steps that contain information about the environment, the changes being introduced and the deployment logic to implement the change process for the affected platform(s). Process-driven automation The main features of process-driven automation include: Directly represents how a sequence of execution steps need to be performed. Represents both human actions and machine integration processes. A process represents how the environment changes, but does not understand the environment layout. They are tightly coupled. Logical steps contain hard-coded information about settings, context, and environment, that make it difficult to abstract. Today many processes are implemented using software-based flowchart diagrams like the one below: Flowcharts are very well known from computer science textbooks. They were initially meant to represent control/sequencing logic at a conceptual stage. Its original use was not intended for execution or automation, certainly not in the context of day-to-day automation of the complex delivery logic that can be found in most IT departments within decent sized organizations. Especially sequencing delivery logic drives delivery complexity. Why? Because the sequence “depends” on many different events that occur during the process. Representing all options up-front can be challenging. Often as a result, the process charts become unwieldy to read and oversee when the complexity of the delivery process is high, which is often the case when there are a lot of application interdependencies. Simple but risky To conclude, process or script driven automation is often perceived be simple, especially if the automation tool is very closely aligned with the platforms it supports (same as with a programming language in the analogy I used) and if delivery complexity is low. The approach is very well appreciated by developers because it gives them a solution and the power very similar to what they experience within their development environments: autonomy and control being the most important ones. The biggest challenge I repetitively hear about is its tight coupling, resulting in many different “clones” of the same script/process being used for deployment onto different environment or for different applications etc. Unless there is a strong governance process supporting the change and use of such processes, the risk can be very high that what was put into production is not entirely the same as what was tested in UAT or QA… Not sure business users and product owners will appreciate that thought. In my next blog session, I will take closer look at model-driven automation, a more recent alternative to handle deployments with more opportunity for reuse and far less coupling. Read next: Model-based Automation 2/4 Get an early start and try Clarive now. Install your 30-day trial here.
A DevOps REPL Clarive SE 7.0.8 has a new exciting feature, a Read-Eval-Print-Loop, also known as a REPL. The Clarive REPL now supports rulebook code. In fact that’s the only language available in Clarive SE. Clarive EE also has server-side JavaScript, which is useful if you develop plugins. Having a rulebook REPL means you can try out your rulebooks in your browser environment. This is a great tool for learning how to write rules and pick up a few rulebook chops. No Events The rulebook REPL will only run a do: section, since in the REPL environment there are no when events set up like there usually is in a pipeline or event trigger. Say you want to try a simple hello world example: do: - friends_name =: Mary - echo: "hello world, ${friends_name}" Write the rule into the REPL and hit the Run button. In the Output tab there the execution standard output will be shown: Appended underneath to the output is the stash, which holds a set of global variables and the variables created by your rule. Ace Editor The REPL interface is a an Ace Editor web component, which is a very powerful editor, at least for a web code editor anyway. So you have plenty of keyboard shortcuts to help your edit and navigate. For a list of available Ace Editor shortcuts, check this link out: https://github.com/ajaxorg/ace/wiki/Default-Keyboard-Shortcuts You can also use the multi-cursor feature, which makes editing large files fun. Benchmarking One of the great uses of the REPL is to benchmark your rule. You can monitor how long it takes to execute a instruction by observing the Elapsed: field on the upper right corner: Workspace If you want to test your rulebooks with files, you can create temporary workspaces by instructing clarive to clone your Git repo right in the rulebook. workspace: - MyProject/MyRepo:master do: - ls /clarive/MyProject/MyRepo - ship: host: myremoteserver # you'll need to create your credentials first from: MyProject/MyRepo/file.txt to: /opt/remotepath/ The above example will run make the contents of the repository MyRepo available to your rulebook. The repository MyRepo belongs to the project MyProject in this example, so you also need to include the project in the path. History and saving The REPL snippets are automatically saved into the history list on the left. That way you can rollback to a previous version of your rulebook in case you something goes wrong. REPL snippets can also be saved. Saved snippets are automatically shared with all users in your Clarive instance. DevOps in a REPL You can install and try out Docker images directly from the REPL using the image: op. do: - image: python - python --version But note: the first time you use it, Clarive will download and configure your Docker container from the hub and set it up for first use. The output will have the following log: [running] $ python --version Python 3.6.3 [done] $ python --version In the above case the elapsed time will be approximately 1m30s the first time you run in our free clarive cloud instance. But the second time around and after that it should only take ~0.5s. To learn how to write rulebooks, take a look at our documentation. Visit our documentation to learn more about the features of Clarive.
Clarive Community Cloud Released Clarive Community Cloud now available with Clarive 7 Code, track and deploy your software releases with Clarive. Get your own cloud instance right now. We’re proud to announce the launching of our community cloud instances. Our community cloud instance is completely free of charge and runs on an dedicated AWS instance and database, preinstalled with Clarive Standard Edition 7.0.8. The instance is limited to 25 users or nodes, which should be more than enough for most teams. What’s Inside Clarive SE If you are asking what’s inside the box, here’s a quick overview: A git repository manager with unlimited private repositories Auto topic-branch management Issue tracking (we call them topics), with scrum and kanban A unique kanban UI, with swimlanes and backlog management A release management workflow CI/CD: continuous integration and continuous deployment pipelines that run in your Clarive cloud instance Deployment environment management Dashboarding Event rules Customizable form fields Here are a few getting started steps: Get your free instance here. Once you get the activation email, login. Create a new Project. Create a Feature topic in the project ⇒ this will create a branch git clone https://[your-instance]/git/[your project]/[your repo] Code and push. Repeat! Yet Another Platform? But why would you need Clarive SE over most of the solutions out there? What we offer is a unique end-to-end DevOps solution that implements a unified topic-based DevOps workflow. Clarive SE should interest you if: You are looking for an end-to-end DevOps solution, from code to track to test and deploy. You want to code your CI/CD logic into your repository (with YAML or any programming language) and not depend on separate pipeline management done by tools like Jenkins or Bamboo. You want your CI/CD to run in our cloud server… then deploy to yours. You always wanted to build projects that are multi-repository You think Git branching and issue tracking should work seamless as one, not 2 separate entities. Under the hood Once on your cloud server you’ll find a complete CI/CD pipeline platform based on Docker. Every pipeline in Clarive job runs in a docker container of your choice. Containers Everywhere Pipeline containers runs in the Clarive cloud server, every time you request a docker container it will be downloaded from the Docker Hub and installed in the server permanently. build: - image: node - webpack ./app.js dist/bundle.js - image: pybuilder - pyb deploy: - ship: host: prodserver from: "dist/bundle.js to: "/opt/app/{{ env }}/" /provision_aws: - echo: "instance type={{ ctx.request('params').type }}" - image: aws All shell commands will run against the container. You can read more in the rulebooks documentation. Upgrading If you run out of users or nodes, or just want more power or storage to manage your code and run CI/CD, our team edition is the most affordable end-to-end solution in the market right now. All our editions are available on-premise as well, in case you prefer to host your own Clarive. For ultimate flexibility and customization you can upgrade to Clarive EE, a full-fledged Application Delivery platform that adds: Visual rule designer for creating custom workflows, topic categories and complex release orchestration Custom reporting and insights Role-based predefined dashboard designer Step-by-step pipeline debugging And an assortment of change providers, including SVN, Visual Studio, SAP, Salesforce, Siebel, Mainframe and other change sources through our enterprise connectors. The Clarive Community Cloud is currently in beta while we test the new provisioning infrastructure and machine configurations. Try Clarive now. Get your custom cloud instance for free.