upd: Ubuntu Lucid howto

Related posts:

1. How to install git on Ubuntu Lucid
2. TODO Items after a fresh Ubuntu install
3. USB devices do not mount in Lucid

Related posts:

1. How to promote artifacts
2. Why did I choose Atlassian suite for my company?

I especially liked the

“Every little feature will be a delight for somebody, especially that person who keeps emailing us because he can’t believe that the feature he wants which is obviously only six lines of code hasn’t been implemented in FogBugz 1.0, 2.0, 3.0, 4.0, “4.5″, or 6.0, and if we don’t get it soon he JUST MIGHT HAVE TO GO OVER TO THE AUSTRALIANS.”

piece.

Is he looking at you, Atlassian? FogBugz still cannot beat your price though.

No related posts.

• Header banner images are 920px × 150px
• located @ http://blog/wp-content/themes/primepress/headers/
• where to look for images?
  • www.flickr.com
  • www.sxc.hu

No related posts.

Why Atlassian?

Atlassian suite provides highly integrated modern comprehensive lifecycle tools that are fully integrated and provide capabilities for the application development infrastructure needed to meet the needs of the most modern development communities.

Atlassian: unified approach

Unified approach to the life cycle:At any time, business analysts, programmers, testers and other participants in the application development process can see what others are doing, and where a project stands. For example:

• Which requirements have been coded, tested and released?
• Which are still works in progress?

Single view of the truth

• Atlassian suite is designed around a common stack of control data where the tools fit in around that data.
• That common set of data is presented through different views of the same information, depending on whether the user of that data is concerned with business requirements, coding, testing, and so forth.
• It is a single view of the truth as opposed to multiple copies of the truth.

Build a release portal

Deliver current release information to

• DEV managers
• IT stakeholders
• Business stakeholders

Related posts:

1. How to promote artifacts
2. What is an Application Lifecycle Automation Server and how does it differ from a Build Management Server?
3. FogBugz 7 and the Australians.

It seems it was  impossible for a long time to find an installp-experienced engineer outside IBM. rpm on the other hand has been freely available for years. For scripty type stuff there should be no special considerations for AIX so the large body of experience, knowledge and example code available for rpm on Linux is very helpful.

IBM is not dropping AIX anytime soon, but at the same time they are actively porting the standard linux tools to AIX and some of the AIX tools to Linux so the environments are converging. This might mean that its only a matter of time before installp become “depreciated” in favor of rpm.

rpm resources

• http://www.ibm.com/developerworks/library/l-rpm1/
• http://www.ibm.com/developerworks/library/l-rpm2/

No related posts.

Set-ExecutionPolicy RemoteSigned

If you’re uncertain what your execution policy setting is, type :

Get-ExecutionPolicy

For reference – these are all supported policy types:

• Restricted
  No scripts can run.
• AllSigned
  Ps1 and .Ps1xml files must be digitally signed.
• RemoteSigned
  Ps1 and .Ps1xml files from the internet must be digitally signed.
• Unrestricted
  No digital signatures are required and all scripts can be executed.

No related posts.

No related posts.

cd /opt
mkdir static_analysis
cd static_analysis/
wget http://downloads.sourceforge.net/pmd/pmd-bin-4.2.5.zip
unzip pmd-bin-4.2.5.zip
ln -s pmd-4.2.5/ pmd

to be continued…

Related posts:

1. How to install git on Ubuntu Karmic

The DEV environment is used by the development team for system integration testing and contains a single server that runs everything. The QA environment is used by the Quality Assurance team to test the application. The UAT environment is where user acceptance testing takes place. In the QA and the UAT environments, there is one HTTP server, one application server, and one database server. The PROD environment is the actual production environment exposed to the world, and contains many load-balanced HTTP servers, a cluster of application servers, and a cluster of database servers.

Because AnthillPro uses the concept of Server Groups to model different environments, Chris configures a DEV, a QA, a UAT, and a PROD server group. He can then add the agents running on each of the machines in those environments to the Server Groups. So the DEV server group will end up with a single agent; the QA and UAT server groups will end up with three agents (one for each HTTP server, one for the app server, and one for the database server). The PROD server group may end up with an agent for each HTTP server, each app server, and each database server; however, this does not necessarily have to be the case and will be impacted by factors such as a shared file system for the HTTP server, using an app server-specific deployment manager, etc. When deploying the application to each environment, AnthillPro uses server roles to ensure that the appropriate pieces of the application get installed on the corresponding machines.

To complicate matters further, each type of server has different credentials in each of the different environments. So the username and password required to make database changes in the DEV environment is different than that required for the QA environment, the UAT environment, and the PROD environment. The same goes for the HTTP servers and the application servers. This is actually a very big piece, and is required for regulatory compliance. Any solution to this problem must make sure that the credentials for a particular environment are never exposed to an unauthorized user. So a developer that can deploy the application to the DEV environment should not be able to deploy the application to the QA, UAT, or PROD environments; nor should that developer have a way of accessing any of the credentials for the servers in those environments.

AnthillPro easily handles this situation. The credentials for servers in each environment can be stored in a secure location and referenced by the Job Configurations in AnthillPro (using parameters that are resolved at build-time). The same workflow configuration could be used to deploy the project to each environment, and at build time the workflow would resolve the parameter that returns the name of the server group that is the target of the Workflow Case. Based on this, the proper selection of the credentials can be performed at build time in a secure fashion.

In Chris’ organization, any developer may deploy the project to the DEV environment to test changes. But promoting a build (Build Life) to the QA environment follows a very different process. The development lead decides what build (Build Life) is ready to be promoted to the QA environment. Then the QA manager is informed and it is up to the QA manager to decide when the new build (Build Life) is to be actually deployed in the QA environment. This way, if the QA team is not ready to receive the new build (Build Life) one will not be forced on them.

These types of hand-offs are explicitly supported by AnthillPro using manual tasks. Chris would configure two additional workflows for the project in AnthillPro, a Promotion-Request Workflow and a Promotion-Approve Workflow. The Promotion-Request Workflow is the one that would be invoked by the development lead on a Build Life that is ready to be promoted to QA. This workflow would create a manual task for the QA Manager role in AnthillPro. Upon affirmative completion of this task, AnthillPro would run the Promotion-Approve Workflow on the Build Life. The Promotion-Approve Workflow would be responsible for orchestrating all the activities and jobs required to promote the Build Life and install the application in the new environment. The same two workflows would be used to promote the Build Life from the QA to the UAT environment; only the target server group would change.

The QA team requires that all builds (Build Lives) delivered to them have successive identifiers. This can be difficult to implement, especially if the development team practices Continuous Integration and generates 10 or more build identifiers per day. The only way to ensure that each build (Build Life) released to QA has a successive identifier is to generate a new identifier for the QA team. Chris can configure multiple Stamp Styles to support the multiple identifiers being applied to each Build Life. This way, during the first stage of the Build Life (the build), the Dev Stamp Style is used to generate the identifier. Later, during the stage when the Build Life gets promoted to QA, the QA Stamp Style is used to generate a new identifier, guaranteeing that the QA team sees builds (Build Lives) with successive identifiers.

Related posts:

1. What is an Application Lifecycle Automation Server and how does it differ from a Build Management Server?
2. Why did I choose Atlassian suite for my company?