Automation of application deployment

• US 8,943,493 B2
• Filed: 11/18/2008
• Issued: 01/27/2015
• Est. Priority Date: 11/18/2008
• Status: Active Grant

• Current Assignee: Red Hat, Inc. (International Business Machines Corporation)
• Original Assignee: Red Hat, Inc. (International Business Machines Corporation)
• Inventors: Schneider, James P.
• Primary Examiner(s): Chen, Qing
• Application Number:
  US12/273,306
• Publication Number:
  US 20100125840A1
• Time in Patent Office: 2,261 Days
• Field of Search: 717120-123, 717168-178
• US Class Current: 717/172
• CPC Class Codes: G06F 8/65 Updates security arrangements therefor G06F21/57
• CPC Class Codes: G06F 8/71 Version control security arrangements therefor G06F21/57; Configuration management

Abstract

Some embodiments of automating application deployment have been presented. In one embodiment, a production repository is created in a federated source code management system to accept software from only a single committer. The production repository is coupled to a set of repositories. Platform management infrastructure monitors the production repository for changes to the software. Further, the platform management infrastructure may automatically push the changes to one or more repositories affected.

Claims

1. A method comprising:

creating, using a processing device, a production repository to accept software from only a single committer, wherein the production repository is communicably coupled to the single committer and a plurality of repositories, wherein the production repository does not pull the software from the plurality of repositories, and wherein the plurality of repositories are allowed to pull the software from only the production repository;

monitoring, using the processing device, the production repository for changes to the software by periodically checking the production repository;

when there are changes to the software in the production repository, pushing, using the processing device, the changes to the software from the production repository to one or more of the plurality of repositories affected by the changes to the software in the production repository;

creating, using the processing device, a stage repository based on the production repository;

creating, using the processing device, a quality assurance (QA) repository based on the stage repository; and

pushing, using the processing device, the software through the production repository, the stage repository, and the QA repository sequentially.

2. The method of claim 1, wherein the plurality of repositories are logically separate from each other.

3. The method of claim 1, wherein the plurality of repositories comprise a quality assurance (QA) system.

4. The method of claim 1, wherein the plurality of repositories comprise a developer source code repository.

5. The method of claim 1, wherein the changes to the software comprise one of an update or a new configuration to the software.

6. The method of claim 1, wherein one of the plurality of repositories is associated with a module running on a first server and other of the plurality of repositories is associated with the module running on a second server, and wherein the first server is separate from the second server.

7. An apparatus comprising:

a memory; and

a processing device coupled to the memory to retrieve instructions from the memory and, in response to executing the instructions, the processing device to;

create a production repository to accept software from only a single committer, wherein the production repository is communicably coupled to the single committer and a plurality of repositories, wherein the production repository does not pull the software from the plurality of repositories, and wherein the plurality of repositories are allowed to pull the software from only the production repository;

monitor the production repository for changes to the software by periodically checking the production repository;

when there are changes to the software in the production repository, push the changes to the software from the production repository to one or more of the plurality of repositories affected by the changes to the software in the production repository;

create a stage repository based on the production repository;

create a quality assurance (QA) repository based on the stage repository; and

push the software through the production repository, the stage repository, and the QA repository sequentially.

8. The apparatus of claim 7, wherein the plurality of repositories are logically separate from each other.

9. The apparatus of claim 7, wherein the plurality of repositories comprise a developer source code repository.

10. The apparatus of claim 7, wherein the plurality of repositories comprise a quality assurance (QA) system.

11. The apparatus of claim 7, wherein the changes to the software comprise one of an update or a new configuration to the software.

12. The apparatus of claim 7, wherein one of the plurality of repositories is associated with a module running on a first server and other of the plurality of repositories is associated with the module running on a second server, and wherein the first server is separate from the second server.

13. A non-transitory computer-readable storage medium embodying instructions thereon that, when executed by a processing device, cause the processing device to perform operations comprising:

creating, using the processing device, a production repository to accept software from only a single committer, wherein the production repository is communicably coupled to the single committer and a plurality of repositories, wherein the production repository does not pull the software from the plurality of repositories, and wherein the plurality of repositories are allowed to pull the software from only the production repository;

monitoring, using the processing device, the production repository for changes to the software by periodically checking the production repository;

when there are changes to the software in the production repository, pushing, using the processing device, the changes to the software from the production repository to one or more of the plurality of repositories affected by the changes to the software in the production repository;

creating, using the processing device, a stage repository based on the production repository;

creating, using the processing device, a quality assurance (QA) repository based on the stage repository; and

pushing using the processing device, the software through the production repository, the stage repository, and the QA repository sequentially.

14. The non-transitory computer-readable storage medium of claim 13, wherein the plurality of repositories are logically separate from each other.

15. The non-transitory computer-readable storage medium of claim 13, wherein the plurality of repositories comprise a developer source code repository.

16. The non-transitory computer-readable storage medium of claim 13, wherein the plurality of repositories comprise a quality assurance (QA) system.

17. The non-transitory computer-readable storage medium of claim 15, wherein the changes to the software comprise one of an update or a new configuration to the software.

18. The non-transitory computer-readable storage medium of claim 15, wherein one of the plurality of repositories is associated with a module running on a first server and other of the plurality of repositories is associated with the module running on a second server, and wherein the first server is separate from the second server.