Continuous Integration and Continuous Delivery Service (CI/CD)

Let's automate everything we can get our hands on

We help organizations build quality software by applying CI/CD

CI is the process in which code is checked into a common repository daily to autonomously build and test applications. CD is the process of promoting a build file from one environment to the next. By applying CI and CD together, we assure that applications are defect free when the application is in the hands of end users. 

This strategy brings development, testing, and operation teams together for the greater good of producing a high-quality application. CI always starts with a main hub. This could be something like CircleCI, Jenkins, or even GitLab. How your organization builds applications today is how we determine the next phase, source code repositories. 

In CI, a source code repository like SVN or GitLab is used for application developers as well as test automation developers to collaborate on code. When code is submitted back into the repo, checks and balances occur before the merge is accepted both at the unit and integration level. Based on the results of a final build process, an application can be promoted. 

There are several environments a build should go through before it is actually released into production…

continuous-integration-tools

Our service configures, integrates, and maximizes the follow environments...

Development Environment 

  • This environment acts as developer’s sandbox
  • Application and backend code should be developed here
  • Each feature being developed should have its own branch
  • Unit testing should be done to check the validity and syntax of code before code is checked in or merged
  • Per feature, test automation engineers have their own feature branch. Test cases are developed for each feature. When complete, the test code is merged. 
  • To assure code validity, we run tests against the latest stable release of an application build to make sure our tests are accurate
  • When all tests pass, through CD, we can promote our application test code to the next environment

Staging Environment

  • As features are completed and tested in development, they get promoted to the staging environment
  • When all feature branches are merged, the application is executed against our test automation framework to assure both quality at the unit and integration level
  • Staging is a place to aggregate any final development features. If a feature is modified in development and passes all tests upon merge request, the application code should replace the existing code in staging. 

Quality Assurance Environment

  • If we need to change something in the production environment, it should occur on QA first against our latest application and latest test code. If everything passes, then the changes are promoted to the production server environment. 
  • Test automation code in QA is final and comes from the master branch of our source code repo.
  • When Application code is promoted to QA, this should be the actual build that will be released to production 

Since this is a direct replica of production, performance tests should be executed as well…

AWS tool stack implementation

Prometheus8 favors a tool agnostic approach to CI/CD, but over the years we have crafted a blend of preferred tools including those provided by our strategic partners. Here is an example of a ‘tool specific’ implementation starting from our agnostic approach for mobile apps.

At Prometheus8 we pride ourselves on having the most up-to-date approach to CI/CD. We help set industry standards when it comes to build promotion and automated testing. Contact us today for a live demo!