Bantotal DevOps is here One of the great initiatives this year for Clarive is the new Bantotal-Clarive integration packaged into a ready-to-use solution and distributed directly through the new and exciting BDevelopers marketplace. We’ve worked closely with DLYA, our partner and the vendor behind Bantotal, to create a comprehensive offering for Bantotal clients and prospects for setting-up a delivery toolchain on top of their Bantotal implementations. Clarive can be the perfect solution for you if: You and your organization would like to create a continuous delivery process around and for your Bantotal customizations and vendor packages and patches (called “zero deliveries”). Coordinate other DevOps pipelines already in place for non-Bantotal systems, but that need to be orchestrated with the rest of your banking core. DevOps is key for making financial systems changes flow at faster speeds without sacrificing quality. The Bantotal platform can greatly benefit from launching DevOps initiatives. managing and deploying to QA and preproduction environments deploy and rollbacking out of production environments orchestrating the deployment of dependent systems making banking core and mission critical changes predictable and repeatable promoting a culture of safer changes and feedback loops withing the teams that work around Bantotal Don’t hesitate to get in touch with us or with the Bantotal team. For more information, please read our Bantotal solution brief.
Bringing DevOps to the Mainframe (4/4) In this last installment of this series, we will review how Clarive can replace z/OS SCM tools such as CA Endeavor or Serena ChangeMan with a global DevOps pipeline that can drive unified deployments across all platforms. Source code versioned and deployed by Clarive Clarive can deploy source code managed outside the mainframe. Selecting elements to deploy In this article, z/OS artifacts (programs, copy books, JCLs, SQLs, etc.) can be versioned in Clarive’s Git, but it could be done with any other VCS for that matter. The developer will select the versions of elements to deploy from the repository view attaching it to the Clarive changeset. Versions associated to changesets Preparing mainframe elements Clarive will checkout the selected version of the source code to deploy in the PRE step of the deployment job and will perform the needed activities to check the code quality (i.e. execute static code analysis, check vulnerabilities, etc.) and to identify the type of compilation to be executed (i.e. decide the type of item depending on the naming convention, parse the source code to decide if DB2 precompilation is needed, etc.). Depending on the elements to deploy, different actions will be executed: Copy books, JCLs and all other elements that don’t need compilation will be shipped to the destination PDSs Programs will be precompiled and compiled as needed and the binaries will be kept in temporary load PDSs Clarive rule will decide what JCL template will be used to prepare/deploy each type of element and will submit the JCL after replacing the variables with their actual values depending on the deployment project and environment. Different z/OS element natures Deploying elements Depending on the elements to deploy, different actions will be executed: Programs will be shipped to the destination PDSs and binded as needed. A Clarive rule will decide what JCL template will be used to deploy each type of element and will submit the JCL after replacing the variables with their actual values depending on the deployment project and environment. Deploy and bind examples As usual, Clarive will keep track of any nested JCL jobs that may run associated with the parent JCL. Rollback Clarive will start a rollback job whenever an error condition occurs in the rule execution. It will automatically check out and deploy the previous version of the elements available in the source repository. Conclusion and the next steps In this DevOps for the Mainframe series, we have exposed the key features of Clarive for bringing mainframe technologies into the full, enterprise-wide continuous delivery DevOps pipeline. Once an organization has decided to modernize mainframe application delivery, there is a set of recommended steps: Establish Prerequisites The first step IT leaders need to take before modernizing mainframe application delivery is to evaluate whether the correct prerequisites are in place or in progress. To successfully implement a mainframe application delivery tool like Clarive requires either an existing process or the will to implement one. Assess Operational Readiness Many organizations discover too late that they have underestimated— sometimes dramatically—the investment needed in people, processes, and technology to move from their current environment for modernizing mainframe application delivery. The early readiness assessment is essential to crafting a transition plan that minimizes risk and provides cross-organizational visibility and coordination for the organization’s cloud initiatives. Many organizations already have some sort of mainframe delivery tools in place. When key processes have been defined within such a framework, optimizing and transforming them to an enterprise-wide delivery is significantly easier, but still need to be integrated into a single Dev to Ops pipeline, as mainframe delivery requests typically tend to run outside the reach of release composition and execution. Prepare the IT Organization for Change This concludes our blog series on deploying to the mainframe. IT leaders should test the waters to see how ready their own organization is for the change the way the mainframe application delivery processes fit into the picture. IT managers must communicate clearly to staff the rationale for the change and provide visibility into the impact on individual job responsibilities. It is particularly important that managers discuss any planned reallocation of staff based on reductions in troubleshooting time to alleviate fears of staff reductions. In this series we reviewed many different aspects for fully bringing your mainframe system up to speed with your enterprise DevOps strategy: Define the critical capabilities and tooling requirements to automate your mainframe delivery pipeline. Decide where your code will reside and who (Clarive or a mainframe tool) will drive the pipeline build and deploy steps. Integrate the pipeline with other functional areas, including related services, components and applications, so that releases will be a fully transactional change operation across many systems and platforms. We hope you enjoyed it. Let us know if you’d like to schedule a demo or talk to one of our engineers to learn more about how other organizations have implemented the mainframe into the overall delivery pipeline. Other posts in this series: Bringing DevOps to the Mainframe pt 1 Bringing DevOps to the Mainframe pt 2: Tooling Bringing DevOps to the Mainframe pt 3: Source code versioned in z/OS
Continuous release readiness checklist ARA is a key DevOps discipline that deals with managing the software and infrastructure changes brought about by a new release. In order to gain a clearer understanding of ARA, we could say that the development lifecycle involves two main areas: Component packaging release and environment planning Readiness and delivery pipeline automation Efficiency in moving releases between environments is an important feature, which we can break down into the following seven subcategories. 1. Deployment Flexibility Deployment needs to be flexible enough to accommodate options (across all platforms and for all environments) such as the following: mapping of dependencies, notifications, creation of shared components, handling of possible manual steps, dealing with concurrent releases, prioritization, window management and integration. Clarive’s rule-driven deployment model approach, which is based on decision trees, allows the system to keep track of the relationship between all artifacts and their configuration, thanks to its graph database. Decision trees may include other releases. Clarive integrated graph database keeps track of the relationship between all artifacts and their configuration. Rules support orchestration of both automated and of manual activities. Clarive features a rule design palette containing the necessary controls for configuring the orchestration scenarios needed: pause job for manual tasks, add approval steps in the job pipeline, Clarive traps an error during the job pipeline rule execution and ask for manual input decisions from the Ops team or equivalent (retry, abort and rollback, skip and continue…) 2. Release Readiness Release readiness features include deployment risk analytics, impact analysis, integration with testing tool results and automated triggering of quality gates based on test case results and pipeline execution governance. Clarive provides support for release readiness, including impact analysis, deployment risk analytics, integration with testing tool results and automated triggering of quality gates based on test cases. It allows users to customize their experience using dashboards, rules, pipelines and custom reports. Orchestration tracking readiness, which is used to track how close a release is to being production-ready is only possible in an end-to-end orchestration tool model. 3. Deployment Plan Management There should feature a complete GUI for creation and management of role-based deployment plans, and the underlying logic of these should be displayed as transparently as possible. Support for application deployment plan management that should include the following: Control Logic – to enable unrestricted and flexible automation Pipeline Diagram Support – graphical representation of logic DevOps IDE Platform – an Integrated Development Environment for designing development plans A decision tree structure/rule design, containing collapsible sections for each phase, is used in order to provide an overview of the end-to-end build, deployment, and post-deployment process. Should more sophisticated activities be required, nested deployment plans (reusing rules) can help promote readability and logic reuse. 4. Pipeline Governance Pipeline governance includes support for root-cause analysis (RCA) and execution profiling, which serves as an aid when improving software performance. RCA is a method used for problem solving by identifying root causes of faults or problems, and its implementation should be capable not only of tracing a failure to a specific version of a specific component, but also of incrementally patching the component, while highlighting any other components that require similar patching. Clarive Root Cause Analysis Graph Deployment pipelines may be monitored through the built-in monitoring service, and individual steps can be traced and analyzed for execution failures, together with any details available from the OS or tool with which interfacing is performed. Clarive comes with a root cause analysis (RCA) algorithm, whereby the tool contains an extensible database of root causes, and can match failures to said database. 5. Pipeline Recreation Pipeline recreation refers to the ability to rerun a deployment using a previous version of an environment model and/or rule logic, and should also be a supported feature of an ARA application. Clarive can determine which versions of which components were used during the delivery process by capitalizing on our software’s configuration management capabilities. The system can use the exact version of the delivery rules that was used for the deployment at the requested time. 6. Deployment Scenarios Application Release Automation tools should offer flexibility in their support for full-featured deployment styles, thereby ensuring extensibility. Some typical deployment scenarios one should take into consideration: Canary deployments Blue/Green deployments Rolling or phased deployments Hot deployments Dark launch modes Clarive supports any deployment scenario/strategy, including partial deployments, rolling and phased, as well as canary and hot, blue, green, and dark launch modes. 7. Test Data Management Test integration is an important feature, therefore automation of test data preparation and integration with test management suites need to be supported. Clarive release models can include test case and test data selection, with the ability to select the correct test strategy according to the type of release and release contents, as well as control which test data and test sets are to be deployed into an environment, and to scheduling when said deployment is to take place. It is also capable of orchestration and working with any virtualization, automated testing tool and test data management tool featuring a CLI, REST or SOAP interface. How Clarive Lives Up to Moving Releases Clarive greatest strength is moving releases between environments while offering enhanced deployment flexibility, tracking release readiness and management of the release pipeline. Clarive tracks every stage of releasing a change There also features pipeline governance and recreation coverage, with built-in support for rerunning deployments using an earlier version of a given environment model. In short Application Release Automation has a very defined set of criteria for release pipeline management. Clarive matches every one of the standard criteria, and indeed surpasses them if we take into account extra features such as Kanban boards, advanced error control and a complete DevOps IDE platform for creating end-to-end automation, orchestration and collaboration of all the teams and assets involved in the organization of DevOps initiatives. Want to know more about ARA? Check our presentation: Why ARA Matters and learn how to to take control over complexity to deliver a great workflow.
Bringing DevOps to the Mainframe (3/4): Source code versioned in z/OS In this installment of this series we will review how Clarive drive popular z/OS SCM tools such as CA Endevor or Serena ChangeMan as part of your global DevOps pipeline. Source code versioned in z/OS (Endevor or Changeman) In this scenario, the source code to be deployed resides in the mainframe. Selection of objects to deploy Clarive will allow the development user to attach z/OS packages (Endevor orChangeMan) to the changesets for further processing. z/OS packages z/OS repository (Changeman ZMF) Preparing Payload Elements Clarive rules will define the logic to prepare the z/OS packages by executing either online or batch operations that are needed to prepare them (freeze,inspect, generate, execute, etc.) Inspect package operation (Endevor) Deployment of the elements The deployment of the packages will be executed by Clarive by submitting the specific JCL to ship/promote/approve the packages included in the job changesets. Ship package (Endevor) Endevor Ship package sample output Rollback Clarive rule will allow the administrator to define the way to rollback changes. In either Endevor and ChangeMan ZMF it will execute a Backout operation on each package included in the job. Backout package (Endevor) Conclusion Endevor and Changeman are powerful version control tools used in mainframe environments. Fundamentally, they have similar or equivalent workflows for the software configuration lifecycle but often these tools are used independently of the overall enterprise DevOps pipeline. DevOps implementations often leave them out, however they remain critical to deliver and run the critical areas of the business with much newer technologies. With its mainframe orchestration capabilities, Clarive enables organizations with either tool to build better integrated pipelines that brings mainframe changes into the main Dev to Ops stream. Stay tuned for the forth and final installment of these series! Read the previous post of this series and learn about the mainframe features you can find in Clarive and how they are integrated into the system.
Bringing DevOps to the Mainframe (2/4): Tooling In this second part of this blog series we will detail the mainframe features you can find in Clarive and how they are integrated into the system. Clarive Mainframe Features Clarive manages all aspects of the z/OS code lifecycle: Sending files to z/OS partitions Character translation maps and codepages Identify relationships – impact analysis JCL Template Management Submit JCL Nested JCL Management and synchronous – asynchronous queue control Retrieve Job Spool output and parse results Integration rules Clarive z/OS features 3 entirely different integration points with the mainframe. Each integration feature serves a specific purpose Job queue access – to ship files and submit jobs into the z/OS job queue in batch mode. Clarive will track all nested jobs and parse results into the job tree. ClaX Agent – for delivering files into Datasets and/or OMVS partitions and executing z/OS processes online. This is the preferred way of running REXX scripts sent from Clarive to the mainframe. Access z/OS facilities such as SDSF®,ISPF®, VSAM® data records or RACF®. Webservices Library – for writing code that initiates calls from the mainframe directly into Clarive using TCP/IP sockets and the RESTful webservices features of the Clarive rules. Clarive to Mainframe Integration Point Tool considerations Clarive is a tool that allows enterprise companies to implement an end-to-end solution to control the software lifecycle providing countless out-of-the-box functionalities that help solving any complex situation (automation, integration with external tools, critical regions, manual steps through the process, collaboration, etc.) CCMDB – Configuration Items In Clarive any entity that is part of the physical infrastructure or the logical lifecycle is represented as a configuration item (CI). Servers, projects/applications, sources repositories, databases, users, lifecycle states, etc. are represented as CIs in Clarive under the name Resource. Any resource can have multiple relationships with other resources (i.e. an application is installed in one server in production, a user is developer of an application, the Endevor “system x/subsystem y” combination is the source code repository related to an application, etc.) The graph database made of this entities and relationships is Clarive’s Change oriented Configuration Management Database (CCMDB). The CCMBD is used to keep the whole system configuration as well as to do impact analysis, infrastructure requests management, etc. CCMBD navigation Natures / Technologies Clarive natures are special CIs in Clarive that automate the identification of technologies to be deployed by a deployment job. A nature can be detected by file path/name (i.e. Nature SQL: *.sql), by project variable values (i.e. ${weblogic}:Y) or by parsing the changed files code (i.e. COBOL/DB2: qr/EXEC SQL/) Natures list JES spool monitoring Clarive will take care of downloading and parsing the spool output when submitting a JCL in z/OS to split the DDs available in the output and to identify and use the return codes of all steps executed in the JCL. JES output viewer Calendaring / Deployment scheduling – Calendar slots Any deployment job in Clarive will be scheduled and Clarive will provide the available slots depending on the infrastructure affected by the deployment. Infrastructure administrators can define these slots related to any CCMDB level (environment, project, project groups, server, etc…) Calendar slots definition Rollback Clarive rule will allow the administrator to define the way to rollback changes. In either Endevor and ChangeMan ZMF it will execute a Backout operation on each package included in the job. Rollback control Next Steps Features are an important step when picking the right tool to bring DevOps to the mainframe. In the next 2 installments of this series we will review how Clarive can deploy mainframe artifacts (or elements), either by driving popular z/OS SCM tool such as CA Endevor or Serena ChangeMan, or replacing them with Clarive’s own z/OS deployment agents. Read the first post of this series and learn more on how to bring DevOps to the mainframe.
QA Automation: building test plans with Clarive A test plan is an essential part of software development. It is a must if you want to get devs and ops people on the same page. As a guide and a workflow, it reinforces your projects success detecting potential flaws in advance. Tracking is also an important part of the testing process, as changes are applied, the test plan should be updated. Unit test, code QA, performance test, integration and regression test are some of the most common types of software testing, and in some cases they are even compulsory to apply as a previous step to a production deployment. With Clarive you can create a QA workflow that combines manual and automated steps, creating test plans automatically on a pull-request/merge-request, which in Clarive can actually be any changeset (user stories, features, bugfixes, etc.). Test plans can then be used to automate test validation. Like in all software development processes, it’s necessary that each code revision go through a proper testing process to ensure the quality of the product. Automating test plan creation You can also create test plans automatically along with the included changes in the version to be released. This feature is capable of detecting the modified files by the developer, create a plan with the test cases (automated and manual tests) that have impact over the modified/created functions and link them to the release. Clarive will only add the test cases that are directly affected by one of the functionalities modified in the release. This way Clarive creates a test plan suitable for each release and if the user wishes to, automate the test cases and depending on the results execute the required actions. Download our whitepaper: The Value of DevOps for Test & Quality Managers and learn more about how to minimize the risk of product failure with Clarive.
Clarive 7.0.13 released with custom kanban card layouts This release contains a lot of minor fixes and improvements from 7.0.12. It is also focus on refactoring interface improving the kanban boards. Git repositories navigation on a tab In Clarive 7.0.13 you can find a new Git repository navigation panel completely refactored. You can view sources, navigate branches and tags, compare references and much more. To access the new interface, just navigate to the project in the left panel, expand it and click on the repository node. Load default data by profile Now any Clarive profile (a profile is a predefined set of topic categories, rules and roles that can be loaded in Clarive) can include default data as part of it. ClariveSE profile now includes a sample-html project and two releases with several changes on them. It also automates the launch of 3 deployment jobs to INTE, TEST, and PROD. To get the profile and the default sample data installed, execute cla setup <profile> and answer yes to the question Load default data?. Once you start the Clarive server it will automatically load the profile and the default data. Kanban Board improvements Custom card layout You can now configure the layout of the cards of your Kanban Boards to show the information that you really want to focus on. To configure the layout, go to the board Configuration and select Cards Layout. Auto refresh In the Quick View options panel (click on View button), now you’ll find a switch to toggle the Auto Refresh for this board. It will be updated with changes in the topics shown whenever the board tab is activated. Save quick view by user In Clarive 7.0.13 the options selected in the quick view menu will be saved locally in your browser storage so every time you open the board it will use the last swimlanes, autorefresh, cards per list, etc. configuration you used. Predefined statuses by list Whenever you create a new board, it will be created with three default lists and now it will assign default statuses to these three lists with the following rules: New: Initial statuses In Progress: Normal statuses Done: Final and Cancelled statuses Killtree when job is cancelled One of the most important improvements of Clarive 7.0.13 is the ability to kill/cancel the remote processes being executed by a job when this is canceled from the interface. You can read about this new feature in this blog post Improvements and issues resolved [ENH] Git repositories navigation on a tab [ENH] Clax libuv adaptation [ENH] NPM registry directory new structure [ENH] Add rulebook documentation to service.artifacts.publish [ENH] Return artifact url on publish [ENH] Invite users to Clarive [ENH] Load default data by profile [ENH] Users can choose shell runner for rulebooks [ENH] Kill job signal configured in yml file [ENH] Add default workers configuration to clarive.yml file [ENH] Boards shared with “ALL” users [ENH] Kanban custom card fields [ENH] Killtree when job is cancelled [ENH] Kanabn boards auto refresh [ENH] Make sure to save kanban quick view session [ENH] Filter data according to filter field in Topic Selector fieldlet [ENH] Make sure new created boards have default lists [ENH] Add date fields to card layout configuration [FIX] Check user permissions in service.topic.remove_file [FIX] Make sure user with permissions can access to rule designer [FIX] Make sure CI permissions are working correctly [FIX] Make sure that the ci grid is updated after the ci is modified [FIX] Control exception when running scripts. [FIX] Change project_security structure on user ci [FIX] User without project field permissions can edit the topic [FIX] Make sure React apps work in IE 11 [FIX] Show cis in create menu (standard edition) [FIX] Administrator should be able to delete artifacts in ClariveSE [FIX] When publishing NPM packages with scopes tarball is empty [FIX] Make sure default values from variables are used when adding them [FIX] Make sure notifications are sent only to active users [FIX] Make sure to show username in “Blame by time” option for rules versions [FIX] Remove default values when changing type of variable resource [FIX] Allow single mode in variables resources [FIX] Escape “/” in URLs for NPM scoped packages from remote repositories [FIX] Avoid console message when opening a variable resource with cis set as default values [FIX] Regexp for scoped packages should filter ONLY packages, not tgzs [FIX] Refresh resources from url [FIX] Create resource from versioned tab [FIX] Make sure remote script element always display a final message [FIX] Save variable when deleted default value field in a variable resource [FIX] Make sure topic’s hidden fields are available as topicfields bounds [FIX] Save resource when it does not have to validate fields [FIX] Make sure projects can be added as kanban swimlanes [FIX] Make sure changeset with artifact revision attached can be opened [FIX] Make sure narrow menu repository navigation show changes related to branch [FIX] Formating event data if fail service used [FIX] Make sure that the chosen element is always selected in the rule tree. [FIX] Reload data resource when refreshing [FIX] Job distribution and las jobs dashlets should filter assigned projects to user [FIX] Make sure user combo not have avaible grid mode in topic. [FIX] Make sure that system user are showed in combo users [FIX] Display column data in edition mode for a Topic Selector fieldlet in a topic [FIX] Filter projects in grids by user security [FIX] Make sure in topic selector combo all height size are available [FIX] Ship remote file: show log in several lines [FIX] Skip job dir removal in rollback [FIX] Remove FilesysRepo Resource [FIX] Remove permissions option from user menu [FIX] Make sure when maximized description and choose back in the browser screen layout are showed well [FIX] Remove session when user get deactivated [FIX] Resources concurrency [FIX] Validate CI Multiple option just with type ci variables [FIX] Resource not saved when validation fails [FIX] Make sure that the combos search has an optimal performance. [FIX] Make sure ldap authentication returned messages are available in stash [FIX] Show date and time in fieldlet datetime [FIX] User session should not be removed on REPL open [FIX] User with action.admin.users should be able to edit users [FIX] Make username available in dashboard rules execution [FIX] Make sure collapsing lists saved in user session correctly Ready to upgrade? Just follow the standard procedure for installing the new version. Click here to get it from our Install page. Acknowledgments Join us in our Community to make suggestions and report bugs. Thanks to everyone who participated there. Try Clarive now and start improving your DevOps practices.
Why environment provisioning is a key part of DevOps? Environment provisioning is a key part of a continuous delivery process. The idea is simple: we should not only build, test and deploy application code, but also the underlying application environment. Are your environments being provisioned on-demand as applications deploy? Can Devs request new environments to fit changes in how the application is built? Is environment configuration and modeling built into the application deployment process? What is the “environment” The application environment consists in 3 main areas: Infrastructure Configuration Dependencies Infrastructure is the most important element of the environment, as it defines where the application will run, the specific configuration needs and how dependencies need to interact with the application. Configuration is the next most important aspect of the application environment. Configuration dictates both how the application behaves in a given infrastructure and how the infrastructure behaves in relation to the underlying application. Dependencies are all the different modules or systems an application dependes on, from libraries to services or other applications. What is infrastructure today? The concept of infrastructure refers to the components, hardware, and software, needed to operate an application service or system. But, as hardware has been abstracted away in favor of scalable, reliable and affordable solutions, the true definition of infrastructure is something different to every application. We could say infrastructure now advances almost as fast as application technologies and languages themselves. Infrastructure has melded with the application in such a way that now we have to basically pick the infrastructure as part of the architecture decisions. Infrastructure has never stopped evolving: virtualization, or how to provision infrastructure in minutes instead of days containerization, or how to provision infrastructure in seconds instead of minutes the cloud, or how to provision infrastructure you do not own serverless, or how not to provision infrastructure as it will provision itself on demand and so on… And the IT infrastructure is not just vertical, but also horizontal, as platforms can also connect many services pods and execution silos. How about configuration and dependencies? Configuration and dependencies are very profound topics that deserve their own articles. But let’s say that today both tend to be containerized one way or the other, meaning both programming languages and infrastructure technologies promote the packaging of environment configuration and dependencies as part of the deliverable. Business Challenges For any organization to successfully test and release new applications or application versions, the appropriate environment(s) needs first to be in place. The enterprise follows many different procedures for supplying environments to applications. It may be manual or automated, or a combination of both. It also may be in the hands of different teams or roles within the enterprise, from developers to operations and sysadmins. Environment provisioning is how an organization manages infrastructure before, during and after the lifespan of an application or service. Environment provisioning is independent of Services Oriented Architecture (SOA), micro-services or a full MVC application, or any other execution structure as running services or application all need to Before: setup development and unit-testing environments and basic SCM controls. Provision environments as the delivery flow advances. During: applications change with new requirements or bugs, and they may need to scale current or provision new features of its infrastructure as they go. After: when done, decommissioning environments is important to deallocate valuable resources. Business Benefits Now why would you want to automate environment provisioning? Or yet, how would you demonstrate that spending time automating and building provisioning into continuous deployment can be beneficial at your organization? Reduce Average Time to Provision This KPI offers a direct measurement of the end-to-end process for provisioning new infrastructure, including both physical and virtual machines, processing power, storage, databases, middleware, communication and networking infrastructure among others. IT managers and business users can employ this metric as an indication of the degree to which IT is supporting the ability needs of the business. Reduce Service Complexity Centralizing all environment automation operations in one place simplifies making decisions that affect the business, permitting a quick turnover of scalability investments and impact analysis and change execution when rearranging infrastructure resources to meet new business requirements. Get Service Allocation Insights Measure how to and for how long infrastructure is being used, how fast it’s being delivered and disposed of and what business requirements are behind each request. Greater service efficiency and decreased costs Provisioning and disposing of environments following establish patterns and templates help reduce waste and complexity. Modular environments are also easier to debug and scale as changes only impact in one application instead of a cluster of applications. The bottomline is that modular environment reduce the costs of running tests and are easier to throttle in production, which also translate in applications that only consume what they need at a given time. Use Cases Here a sample of use cases that triggers an organization to implement a provisioning solution: Onboarding new application teams have to deal with organizational complexity and adhere to standards and release policies. Provisioning a baseline environment catalog will help circumvent organizational obstacles and technological challenges. Coordinating code releasing and provisioning to make sure infrastructure changes arrive just-in-time with the code that requires it. Dev and QA environment provisioning, to simplify and control the process of procuring and automating environment generation. Self-service provisioning, offering users a “catalog” with a set of service requests and tasks that can be launched and managed. Infrastructure code is being pushed and continuously deployed by developers (ie. Dockerfiles or Chef recipes), but require more control and end-to-end visibility. Get started today If you feel you’re not taking full advantage of environment provisioning, here’s a few ideas for you to get started ASAP: When starting new apps, or designing architecture, try to predict how environments will be provisioned at different stages during the delivery pipeline, specially QA and Production. Build apps that can have features tested on-demand by spinning throw-away environments. Have your DevOps processes (ie. scripts, builds) run in containers too. Add environment provisioning to your CI/CD pipeline. Offer users a way to control and define the environment rules and infrastructure needs, as code if possible. In general, containers are a great way to go thanks to it’s infrastructure as code nature and natural DevOps fit. Serverless on the other hand can abstract away many environment concerns and make better use of resources as applications grow. Let Clarive be your best friend in your DevOps journey to continuous delivery. Start with your 30-day trial now.