-
Notifications
You must be signed in to change notification settings - Fork 7
Add dev environment setup for JavaBuilder Lambda deployment #406
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
Add alarm for high HTTP requests
…larms Improve performance alarms
Add alert for high Lambda invocations
Set up unit tests for javabuilder-authorizer
Prevent duplicate authorizer warnings
Enable running individual integration tests
Make composite alarm for high request counts
Move error handling logic to the handler level
Add authorizer alarms/alerts to cloudformation template
…o-ci-cd SL-667: Add CICD config for Javabuilder demo env
* reduce concurrency for demo mode * PR feedback
…rency-to-1 Increase provisioned concurrency to 1
next: reduce reserved concurrency
Reduce demo concurrency - step 1
Reduce demo concurrency - step 2
* update daily blocking logic * add config for dev setup * updates * decrease dev limit * update constants * update string * update configs * update prod to have no daily limit * make no limit clearer * try out -1 as no limit
update cicd readme with ruby version fix
* update limit and change alert description * try using version 2.7.5 * try using version 2.7.8 * add dev config * update alarm config * add whitespace * commas * try parens * hard-code limits * add period * temporarily change config for testing * change back to demo config * increase provisioned executions * remove dev config * switch to parameters * fix linting errors * add quotes * revert dev config change
- Add dev-deployment/ directory with complete deployment tooling - Create no-SSL deployment option for dev environments without Route53 access - Add modular deployment scripts (base infrastructure, java builds, application) - Include cleanup and health check utilities - Update CloudFormation templates to use ruby3.2 runtime (from deprecated ruby2.7) - Add comprehensive README with deployment options and troubleshooting - Implement ERB template processing with SSL resource removal - Add proper artifact management and S3 packaging for large templates - Include development configuration files and parameter templates - Create runtime placeholder system for missing Java artifacts Key features: - No-SSL deployment: deploy-javabuilder-dev-no-ssl-fixed.sh - Modular deployment: 01-deploy-base-infrastructure.sh -> 02-build-java-components.sh -> 03-deploy-application.sh - Comprehensive documentation and troubleshooting guide - Idempotent deployments safe to rerun - Proper handling of large CloudFormation templates via S3 - Development-focused with codeorg-dev AWS profile support Successfully tested with complete stack deployment in us-east-1 region.
2d2f71d
to
4e08a43
Compare
…Python artifacts blocks - Removed unused environment configuration script check for ../config/set_environment.sh - Removed Python placeholder artifact creation for Java-based Lambda project - Streamlined script flow for better maintainability
- Align dev deployment script with production buildspec.yml workflow - Use actual build.sh scripts instead of custom build logic - Remove unnecessary base infrastructure checks and discovery logic - Use ARTIFACT_STORE environment variable like production - Replace create-stack/update-stack with modern 'cloudformation deploy' - Use parameter-overrides syntax for cleaner parameter passing - Keep dev-specific SSL removal logic for non-SSL development environment - Reduce script complexity from 300+ to ~285 lines - Improve maintainability by following production patterns
- Remove timestamp from artifact bucket name to prevent creating new buckets on each deployment - Change from 'javabuilder-dev-artifacts-1753199542' to 'javabuilder-dev-artifacts' - Simplify deployment script to use consistent bucket name without discovery logic - This ensures all deployments use the same S3 bucket for artifacts - Reduces S3 costs and prevents bucket proliferation
- Remove unused symlinks (api-gateway-routes, javabuilder-authorizer, org-code-javabuilder) - Remove obsolete deployment scripts and config files - Keep only the working deployment script (deploy-javabuilder-dev-no-ssl-fixed.sh) - Streamline directory structure for cleaner PR review
- Remove 150+ lines of complex SSL removal Python script - Rename to deploy-javabuilder-dev-with-ssl.sh (reflects SSL support) - Copy built artifacts to deployment directory for packaging - Use original SSL-enabled CloudFormation template - Clean up copied artifacts after deployment - Ready for SSL certificate configuration
- Add WildcardCertificateArn parameter to CloudFormation template - Add conditions to use existing wildcard certificate when provided - Update deployment script to check for artifact bucket existence - Switch from cp to rsync for artifact copying to avoid permission issues - Include wildcard certificate ARN in deployment parameters - Update processed template with latest artifact URIs
- Revert rsync back to cp commands to avoid directory creation issues - Add cleanup at end of script to remove temporary copied artifacts - Keep deployment directory clean after successful deployment
- Remove api-gateway-routes, javabuilder-authorizer, and org-code-javabuilder directories - These are temporary copies created during deployment and should not be tracked - Deployment script now properly cleans up these directories after packaging
Do we really want to make a copy of the Javabuilder CloudFormation template ( I think we need to update and document a way for an engineer to provision a development Javabuilder Stack (typically in our AWS Dev account) using the template |
…cket policy - Replace public bucket policy (Principal: '*') with secure CloudFront OAC - Add ContentOAC resource for proper CloudFront to S3 access control - Update ContentCDN to use OriginAccessControlId instead of empty S3OriginConfig - This fixes deployment failures due to S3 Block Public Access settings
Since app-template.yml is auto-generated from the ERB template on each deployment, it shouldn't be tracked in version control.
@sureshc see in |
17f5808
to
b22b906
Compare
Features: