In Response to Matt Raible’s question about my preferred development stack.
Source control
In my own development project I switched to Git some time ago. I was using svn and before that cvs for a couple of years. Git just makes it easy to try out small ideas very quickly without reverting the code. We will introduce Git at work pretty soon (I hope).
The Atlassian cloud
I was using Confluence as a Wiki in my open source project and my current employer Hypoport uses it as well. Bug tracking is pretty much a task of Jira. Those two integrate very nicely. You can have ping backs in your Jira Ticket from Confluence, so you see all related files. I would love to use FishEye but I’m not sure how to justify the costs and what the added value is in our case.
The Code
I’m pretty much sold to Jetbrains IntelliJ Idea. I’m using it for 5 years now. With it comes Teamcity. It’s a very nice continuous integration tool where the biggest plus (among other things) is the delayed (and pre tested) checkin. No more late night checkins which break the master. We just rolled out the latest version which has a much nicer Git integration (so we can make the switch).
So it comes down to:
The List
- Source control: Git
- Wiki: Atlassian Confluence
- Continuous Integration: Jetbrains Teamcity
- Bugtracker: Atlassian Jira
We are about to use Sonar for code analysis and development over time, but this is just in the beginning.
What’s yours ?
4 Responses to “What’s your preferred development infrastructure stack?”
Leave a Reply
Additional comments powered byBackType
my preferred development infrastructure stack http://bit.ly/4SctZN
This comment was originally posted on Twitter
Hey,
I’ll tell you about mine:
For source control and the code I’m bound to use transaction SE80 (or one of its siblings like SE24), which is a SAP base transaction for ABAP development.
Here I have some sort of version tracking which allows to compare different versions of the code. Positive to remark is the feature to compare code across the system landscape, to compare code of the productive environment with the one in the dev. environment.
The ABAP editor offers sort of syntax highlighting and suggestions for completion on key words and variables. Code consistency is checked with Alt-F2.
I don’t know about other debuggers, but I like what I have with SAP’s new debugger. All the fields and run-time information directly accessible. I could get insight into table content and manipulate every attribute.
What I never used is the Code Inspector, which, ok, inspects the code, unreached passages, infinite loops thinks like this. The inspection could be scheduled, so sort, of CI as continuous integration is possible. Also scheduable from the Code Inspector is the execution of unit tests.
Finally I need to mention that we do a very straight forward coding in our BW system. No super generic stuff. In general structural and type information are at hand and we simply add some business logic. Beside this there are some neural core components like changed data capturing, or generating surrogate keys. More or less we are forced by SAP to use ABAP Objects, but not in the OO way.
Bug tracking depends on the systems. Unwanted features visible to the customer are tracked by central, and group wide Pergrine Service Center. Those are called incidents, get an priority and development team assigned, and are to be solved. Bugs in the development system are tracked by using… words. So the small team responsible for a set of applications in SAP BW know, because hear, that there is an issue.
That my infrastructure stack. As I have no options this is my preferred one
Go ahead, Olli!
Just commented on http://bit.ly/4SctZN
This comment was originally posted on Twitter
Just commented on http://bit.ly/4SctZN
This comment was originally posted on Twitter