|
|||||
|
This new release includes amelioration for GreenPepper Open and the GreenPepper plugin for Confluence. We are still working on the Greenpepper plugin to made it compatible with Confluence 4.0. The plugin model is completely different than before in this new version of Confluence so it requires a bit more time. We are about to release GreenPepper 3.0 so stay tunned! See the release notes for more details… Hi all, We are actually aware that GreenPepper is not compatible with Confluence 4.0, .Net 4.0 and the last version of Jira, Bambo and Xwiki. The fact is that GreenPepper is no longer managed by Pyxis Canada. The product was transferred to the new subsidiary of Pyxis in Switzerland and the development was halted for several months during this process. The good news is that the swiss team took the product back on hand a few weeks ago and are actively working on those compatibility problems. We planned a new release for November that will make GreenPepper works with Confluence 4.0, .Net 4.0 and other systems. Support and product development are always assured and we will make every effort to answer all your questions and deliver a product tailored to your needs. Best regards, The swiss GP team. This new release includes a performance improvements for the Hudson plugin, use of Maven coordinates for the Maven Runner, greenpepper-include-macro now available for the XWiki plugin, many improvements to the core and much more… See the release notes for more details… We are proud to announce that a pre-release of GreenPepper for C++ developers is available! This release supports both Atlassian Confluence and XWiki wikis. So C++ comes today to enhance the existing list of software development platforms supported by GreenPepper (Java, PHP, .NET, Ruby). This pre-release has been developped in 2 months in C++ using full test-driven approach thanks to the GoogleTest framework. Compiled langages (like C++) are pretty challenging regarding the lack of mechanism like runtime type informations (or reflection). Our team took the challenge and got inspired by the same solutions as those retained by Google. Our team hid complexity as much as possible, to allow GreenPepper C++ users to program with a simple source code (hum… although “simple” with C++ does not mean the same with other langages Want to see what a fixture source code looks like? Below a C++ header file sample :
If you want to start using executable specifications within you C++ projects, just tell us! Please contact us at grenoble@greenpeppersoftware.com. Download the package here. Kind regards. As you may have noticed in the Executable Specification and build integration post, build system integration is an area where GreenPepper shines. Most teams having good automated build practices also use a continuous integration (CI) server. We provide more comfort to those teams by allowing them to look at their GreenPepper execution results directly from their CI server user interface, we have developed integration with two major CI servers: Bamboo and Hudson. Bamboo Build View : If you would like us to develop an integration with your favourite CI server, let us know. This new release includes a new plugin for Hudson (a continuous integration server), support for Jira4, a better use of accented characters in specifications, many improvements to the core and much more… See the release notes for more details… Éric Laramée, a colleague at Pyxis the other day was recalling the Greed is good scene from the movie Wall Street
We the started to play with that quote and here is the result:
We had a good laugh and thought it was very cool! Some developers are asking me : How do I tag my specification when I do a release or close a development branch while GreenPepper does not provide full SCM capabilities in the wiki. I explained in Why we did not implement a full SCM for specifications why we did not think it was a good idea to implement full SCM capabilities in the wiki. To achieve the need stated above, we have implemented in all our build system integrations (Maven, MSBuild and Nant) a feature called freeze, what this does is simply going to the wiki server to get the specifications and store them locally. See the documentation to learn what you need to do in your build script. You simply commit those files and tag them with your source files. Couldn’t be simpler! Life is Green! You can even come back months after the release and execute the specifications locally from your IDE or from the command line. Life is Greener! In the Executable Specification and Build Integration post, I explain how GreenPepper supports the full development cycles. Some people sometimes ask me why we do not have full SCM features with branches, tags and merge in the wiki integrations that we have. GreenPepper promotes a very inclusive approach and we thought that customers and users involved in development team would find it too technical and would be confused by branching and merging features. In GreenPepper the users simply modifies and save. He doesn’t even need to understand versioning. It cannot be simpler.
Some developers ask me: But how do I keep track (tag) of the specifications when we do a release. I cover this in details in the Put your specifications in the freezer blog post. It is usually not long after adopting the Executable Specification practice (aka Example Driven Development, Acceptance Test Driven Development – ATDD, Story Test Driven Development – STDD) that good software teams want to integrate GreenPepper in their build process. This is an area where we think GreenPepper shines. Let me walk you through what happens. At the beginning (and during) of an iteration or sprint some specification pages are modified or added. GreenPepper keeps track of the implemented vs working copy.
The various build tool integration we have (Maven, MSBuild, Nant …) will continue to use the implemented version therefore your build is not broken and you do not need to move the modified or added pages in a temporary area. Great! At some point a developer will assign himself to the implementation. In his favorite IDE (Eclipse or Visual Studio) he can easily locate the modified specification page and switch to the working copy
Then he executes the page and should see the page not passing
Then he goes and develop the code TDD style with his favorite unit testing tool integrated in his IDE (JUnit, TestNG, Visual Studio, Nunit, etc.) He can frequently re-execute the page and see it slowly turn from red to green! Once it is all green, he commits his code in the source control and from the IDE he sets the specification page as implemented.
The next build will use the committed code and page and life will be Green! |
|||||
|
greenpepper is grown by Pyxis Technologies |
|||||
)
