Fabric 链码开发,开发模式下的测试

关闭之前已启动的网络环境

sudo docker-compose -f docker-compose-cli.yaml down

进入devmode目录:

/fabric-samples/chaincode-docker-devmode

启动测试网络

sudo docker-compose -f docker-compose-simple.yaml up -d

启动新窗口建立并启动链码:

 sudo docker exec -it chaincode bash

原文地址:https://www.cnblogs.com/zhanghh/p/11597803.html

时间: 2024-08-29 21:04:05

Fabric 链码开发,开发模式下的测试的相关文章

敏捷开发模式下的测试工作

在华为业务线上有近40天的时间了,参与了两个版本,华为的项目大多数走的都是敏捷迭代开发模式了,至于什么是敏捷,网上有很多的解释与资料,这里就不阐述了,就说说这期间华为的一个敏捷模式. 敏捷开发的最大特点是:积极响应用户的需求,快速高质量的交付软件.所以很多需求会按照用户需求程度以及模块之间的关联程度划分为多个迭代,这里的迭代你可以看做是一个小的完整的版本周期,每个迭代包含多个story,一个story相当于一个功能点,一个小的需求,而一个大的完整的发布版本一般由几个迭代版本组成.敏捷开发的周期一

敏捷开发模式下的测试

敏捷开发 敏捷开发倡导的就是迭代式和增量式的开发模式,并且强调测试在开发过程中的重要性 .主要是围绕以用户为中心,以客户需求为导向的开发过程,这个过程有一个特点就是"随时有变化".虽然敏捷开发引入了灵活性,但其中的重点还是在于客户满意度.客户是敏捷过程的关键环节.如果,客户能够有所参与,并且客户了解到开发对于他们参与的欢迎,那么有助于增加客户对最终产品和开发team的信心和满意度.如果客户由于其他原因不愿意参与进来,那么选择传统的开发流程更好.敏捷开发有三个比较明显的特征:依赖客户完成

Node.js SDK与fabric链码交互开发

1.本篇背景 前面已经对链码开发作了比较详细的介绍,并且对官方提供的 fabcar 链码进行了解读,本篇将介绍如何使用 Node.js SDK 与区块链网络中的链码进行交互. 本篇内容基本来自官方 Hyperledger Fabric 文档中的 Writing Your First Application 章节,对文档进行翻译,原文网址如下: http://hyperledger-fabric.readthedocs.io/en/latest/write_first_app.html 主要根据谷

HyperLeger Fabric开发(八)——HyperLeger Fabric链码开发测试

HyperLeger Fabric开发(八)--HyperLeger Fabric链码开发测试 一.链码实例 SACC项目链码实例如下: package main import ( "fmt" "github.com/hyperledger/fabric/core/chaincode/shim" "github.com/hyperledger/fabric/protos/peer" ) // SimpleAsset implements a si

HyperLeger Fabric开发(七)——HyperLeger Fabric链码开发

HyperLeger Fabric开发(七)--HyperLeger Fabric链码开发 一.链码开发模式 1.链码开发模式简介 Fabric的链码开发调试比较繁琐.在不使用链码开发模式的情况下,链码不能在本地测试,必须部署到docker,install和instantiate后,Peer节点会在新的容器中启动链码.但只能通过docker logs查看链码日志,通过打印日志的方式进行链码调试.如果对链码进行了修改,需要重新开始上述流程.为了简化Fabric链码开发的调试过程,Fabric引入了

混合开发模式下主流移动开发平台分析

关键字:AppCan 移动开发平台 移动应用 Hybrid App在过去的两年中已经成为移动界的核心话题,但是作为一名Web开发者来说要如何站在移动互联网的浪潮之巅呢?是选择学习原生开发,研究Java.Object-C.C#等语言,还是选择继续使用网页开发,容忍HTML5功能的局限性?就在开发者左右为难的情况下Hybrid App作为一个折中的解决方案诞生了.那么究竟什么才是Hybrid App呢?HybridApp概念Hybrid App:Hybrid App is a mobile appl

敏捷开发模式下的自动化测试研究

敏捷测试过程中的自动化目前在国内来看基本上还只是停留在概念阶段,据我所知,目前不少公司也都在尝试过程中,而实际的实践中能取得比较理想成果的,极为有限.而国外不少同仁也都对此持观望甚至抵触的态度.比如advanced QTP论坛的administrator Meir大大 就认为敏捷过程中的自动化是完全不现实的,理由就是sprint间隔时间内没办法完成一个完整自动化过程的设计,而频繁的变更会导致自动化资源的大量浪费,ROI上无任何前景可言. 从我个人观点来看,没必要保持如此的悲观,但更不能过于乐观.

IPD模式下开展敏捷开发的一些问题汇总

1.      我们现在普遍用的是老系统情况下,什么时候把软件和硬件在敏捷项目里面集成? 答:有两种场景:第一种场景是把软件分几个迭代,最后把软件和硬件一起集成:第二种场景是更好的一种场景,每几个迭代后,就把开发出来的部分软件和硬件在一起集成测试,不管这个硬件是开发了一部分或者是整体,软件完成后,在迭代末尾做一个更广泛的整体测试.总的来说,集成和测试越早开始越频繁越好.有个医疗仪器公司,他们有一个非常庞大复杂的系统,这家公司为了提高仪器质量,甚至改变硬件开发流程,把软件分成多个模块来开发.每开发

简介Intel MIC上的分布式开发以及Offload模式下的各种限制

最近要在MIC机群上做分布式开发,发现有两种模式可以用: 1) offload模式:该模式和GPGPU编程思想类似,把并行度高的代码转移到local的MIC处理器上执行,其它代码仍然在CPU上执行.MIC只负责本地计算,分布式通信必须在CPU上执行. 2)symmetric模式:编译出在MIC和CPU上执行的两份二进制代码.该模式逻辑上允许MIC进行分布式通信,虽然物理上消息还是从CPU走的.这种模式编程最大的难点是load balancing问题. 通过几天探索,发现了offload模式下的各