8. Purpose
Automated deployment of source code to SIT, UAT, PRD
On-premise servers
AWS servers
Structured process to keep track and manage
Application Change Requests
Bug Fixes
Allows multiple developers to work together on same pieces of source codes
Ease of development
No overwriting / confusion of source codes
Easy rollback
Focus on development work NOT deployment details
9. Features
Incremental code updates
Commit codes directly from SVN to Redmine issues
Release management by Issues
Email notification report on deployment details
Automatic SVN tagging for each successful releases
Publish builds events directly to Slack Channel
16. Redmine Issue Status Transitions
NNeeww
FFixix i nin P Proroggreressss
PPeennddiningg C Cooddee P Prorommootitoionn S SITIT
RReeaaddyy f ofor rR Reetetests tS SITIT
PPeennddiningg C Cooddee P Prorommootitoionn U UAATT
RReeaaddyy f ofor rR Reetetests tU UAATT
PPeennddiningg C Cooddee P Prorommootitoionn P PRRDD
RReeaaddyy f ofor rR Reetetests tP PRRDD
RReesosolvlveedd
deploy
deploy
deploy
17. Step 1 – Create a New Issue
Click on Create to create a new issue
18. Step 1 – Create a New Issue
Take note of the Issue #.
It will be used later.
19. Step 2 – Commit Code Changes
Input the Issue # here
i.e. “ref #26“
20. Step 2 – Commit Code Changes
Notice that the Status
has changed from “New”
The SVN changes previously
committed using the keyword “ref #”
instructs the SVN Revision
to be linked to the Redmine Issue
21. Step 2 – Commit Code Changes
Redmine allows you to view
the details of the changes for
the SVN Revision # 365
23. Step 3 – Promote Code
Change the Status to Promote
code changes in Issue #26 to
the next environment.
eg. SIT in this case.
24. Step 4 – Trigger Jenkins Build & Deploy
A build #166 is triggered
in Jenkins when the
Status is set to
Pending Promote
25. Step 4 – Trigger Jenkins Build & Deploy
Automatically generated
SVN commit message
to the Branches deployed
(eg. SIT)
Details of the Build #166 can be seen viewed here
26. Step 4 – Trigger Jenkins Build & Deploy
Jenkins will commit the changes in Build #166
to the Branches (eg. SIT) for delivery to the (eg. SIT) Servers
27. Step 5 – Deploy Changes to Server
A SSH connection inside the SIT Server
Changes are deployed to the actual Servers (eg. SIT)
from the SVN Branches Repository (eg. SIT)
28. Step 5 – Deploy Changes to Server
An email notification
of a successful deployment
of code changes
to the relevant people
in the Redmine Issue #26
29. Step 5 – Deploy Changes to Server
An example of an email notification
of a error and failed deployment
to the relevant people
in the Redmine Issue #10
30. Step 6 - Testing
Upon a successful Build or Deployment
the Redmine Issue Status will be
set to the “Ready for Retest” status
31. Step 7 – Auto Tagging Backup
In a successful Post-Build/Deployment, an automated Tagging will be committed
under the SVN Repository folder:
-> tags -> last-successful -> environment
for backups as well as a means for rollback of released code versions.
32. Step 8 – Publish Build Events to Slack
Optional:
The system also allows Build events
to be published to Slack channels
of your choice.
33.
34. Vision & Possibilities
1. To address the shortcoming of the more rigid 1st generation Mantis
Deployment system.
2. To put many projects that are still deploying codes manually on a flexible,
automated deployment system, as well as a systematic and trackable release
management.
3. To relieve developers the laborious and unorganised manual work of
accessing servers for code deployment and concentrate on more productive
development work.
4. To improve the time-to-market of application features and bug fixes without
sacrificing quality. More quality releases in a shorter time.
5. To give teams intending to embrace Agile, Scrum, Test-driven Development
methodology, Automated Unit Testing, DevOps, etc, a tool to aid in their
cause.
35. Vision & Possibilities
6. To provide mobile developments a tool for automated simulation testing of
different devices.
7. To enable teams embracing AWS Cloud computing a systematic framework
to fully automate the deployment of infrastructures and system administration
operations.
8. To allow teams to make use of container tools like Docker to develop
applications that are much more portable and efficient across deployment
environments.
9. To provide for teams to eventually be able to fully automate the functional and
performance testing of their apps that seamlessly integrates with release
management.
10.To eventually be able to have a true Continuous Integration system that fully
automates release management and delivery, hence saving time, improving
productivity and efficiency with a peace of mind.